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(57) Abstract: A supply chain network where customers, suppliers, logistics providers, carriers, and financial institutions are all 
00 connected to a centralized supply chain server. The server receives forecasts from the customers detailing the orders that the cus- 

tormers desire. These forecasts are analyzed by the supply chain server to ensure that they conform to contractual agreements and do 

not contain errors. The forecasts are also used to warn the suppliers of future demands so that the suppliers can anticipate demands 
1^ and plan inventory accordingly. The supply chain server checks with the suppliers to determine whether the forecasts can fulfilled 

by the suppliers. If the forecasts cannot be fulfilled by the suppliers, the supply chain server contacts customers and suppliers and 
^ attempts to either redistribute the customers' demands to different suppliers or request that customers alter their demands. Once 

supplier demand issues are resolved, the forecasts are sent to tlie suppliers in groups so that tlie suppliers need to prepare a smaller 
Q number of large orders. The supply chain server also controls the processes involved in distributing the product from the suppliers 

to the customers including the generation and payment of invoices. A form of financing the customers' purchases, made possible by 
^ the novel supply chain architecture, is also disclosed. 
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SUPPLY CHAIN ARCHITECTURE 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The invention relates to an improved supply chain network and, more 
5 particularly, to a supply chain network which centralizes many operations thereby 
yielding a supply chain that is more efficient and less costly than prior art systems. 

Description of the Related Art 

Manufacturers (hereinafter generally referred to as "customers") and 
suppliers of products or services (hereinafter collectively referred to as "products") 

10 are continuously mterested in reducing costs. Materials make up a large fraction of 
total costs as do supply chain management costs. A supply chain is any and all 
activities associated with defining, designing, producing, receiving, monitoring, 
storing and using the components and sub-components used in manufacturing a 
product. Manufacturers/customers often find themselves paying higher prices, 

15 being short of products in times of high demand, forecasting needs inaccurately, 
and creating slow moving inventories because these manufacturers do not have the 
expertise, resources or time to manage their supply chain properly. 

Direct materials account for between 35% to 70% of a manufacturer's 
total costs and often constitute the largest expense category; Lowering material 

20 costs significantly improves profitabiUty. For example, a company in the business 
of contract electronics manufacturing could improve overall profitability by 20% to 
30% fi*om only a 1% drop in direct material prices. 

Supply chain costs also constitute a significant fi-action of a 
manufacturer's total expenditures. For example, supply chain costs include: 
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planning, purchasing, inboimd freight, receiving, inventory management and 
carrying costs, supplier monitoring, measurement, management, and the 
payment of invoices. These costs can account for between 5% and 25% of 
corporate expenditures- That estimate applies to both the manufacture and 
5 supply of the manufacturer's components. For example a 20% reduction in 
supply chain costs would significantly improve, and in many cases could 
double, the profits of a given manufacturer. 

A typical prior art supply chain is shown in Fig. 1 . Customers 
generally have two methods for procuring components and sub-components 

1 0 using prior art supply chains. As shown in prior art supply chain 50, large 

original equipment manufacturers ("OEMs"), contract electronics manufacturers 
("CEMs" - not shown) or customers 52 (of components) will typically buy 
directly fi:om a component manufacturer or suppUer 56. This technique is 
known in the industry as "buying direct". Large customer 52 places an order 

1 5 with suppher 56 each time a part is needed. SuppHer 56 gives the products to a 
carrier 58 who, in tum, delivers the ordered products to large customer 52. 

Small customers 54 typically make purchases through a third 
party distributor or agent 60. Distributor 60 purchases parts firom supplier 56 
who gives the products to a carrier 62 who brings the products to distributor 60. 

20 Distributor 60 then transfers the products to another carrier 64 who delivers the 
products to small customers 54. Other types of third party distributors use an 
electronic means to hold auctions for components. However, as the time 
involved in attending the electronic auction is lengthy, such services are rarely 
used except for one-time, or spot component requirements. 

25 Many of the parties involved are not pleased with prior art supply 

chains. Known supply chain networks commonly yield missed shipments and 
discontinuity of component supply to a customer. These deficiencies 
particularly fiiistrate customers in times of "allocation" where there are 
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shortages of key components. This causes delays in end product shipments and 
corresponding loss of revenues and profits. 

Component suppliers 56 in particular are frustrated with prior art 
supply chains. Changes in market conditions for these entities' end products 
5 yield very volatile manufacturing schedules, resulting in inefficient factory 
usage and higher costs. Component suppliers 56 have also invested heavily in 
MRP (Materials Resource Planning) and ERP (Enterprise Resource Planning) 
systems to try to incrementally improve factory loading and inventory levels. 

In these systems, component suppliers plan to provide parts based 

1 0 upon production plans generated by a customer factory or series of factories 
using the same system. However, these systems often produce disappointing 
results because they operate only within each individual component supplier 
and often only process production plans on a weekly basis. As such, these 
systems typically react slowly when compared with the rate of order 

1 5 fluctuations and are unable to detect excess inventories located in non-primary 
warehouses thereby resulting in excess parts being ordered. 

To solve some of these problems, some larger manufacturing 
customers 52 require that suppUers 56 maintain dedicated on-site or local 
consignment inventories of the products these manufacturing customers 52 

20 require. However, maintaining these additional inventory locations is very 
costly and difficult to control. The additional inventories also create further 
inefficiencies in the use or production capacity and total inventory. 

Additionally, customers 54 are often serviced through distributors 
60 who require 7% to 35% gross margin points to manage and cover inventory 

25 handling costs in addition to the supply chain costs akeady borne by these 
customers 54. These distributor margins reduce supplier's 56 profitability on 
small and medium sized customers 54 and produce a tension between suppliers 
56 and distributors 60 on how or whether to limit distributor margins. 
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Furthermore, distribution orders cost more to administer with special processes 
and systems required to manage *'ship-and-debit" pricing and stock rotations. 
Finally, selling and servicing customers costs between 5% and 10% of sales - 
excluding marketing and advertising costs. Suppliers 56 have difficulty finding 
5 a pay-back for these investments. 

There are payment problems in prior art supply chains as well. In 
many prior art systems, products are sold to customers 52, 54 with payment 
terms that are ignored. For example, the customers receive the products from 
suppliers 56 and then have 30 days from delivery to provide payment to 

10 suppliers 56. Customers frequently take advantage of this payment term and 
not pay until after the term has expired, for example, 45 days from delivery. 
Customers find this arrangement more desirable than taking a loan to cover the 
costs of the products and paying the loan on time. By delajdng payment, the 
customers' balance sheets indicate a payable instead.of a loan; a more attractive 

15 view for investors. It is generally not worthwhile for suppliers 56 to complain 
about a 15 day discrepancy but the suppliers 56 lose money during those 15 
days. To solve this problem, suppliers 56 create a de facto interest for money 
expected to be lost due to late payment by charging customers more for parts. 
This de facto interest is clearly undesirable for customers 52, 54. 

20 Moreover, toward the end of accounting periods, suppliers 56 are 

frequently desirous to ship products ahead of schedule to improve the 
appearance of respective balance sheets. Distributors 60 for the suppliers 56 are 
aware of this desire and consequently require suppliers 56 to offer discounts to 
receive goods before scheduled shipments. These extra discounts required by 

25 distributors 60 present yet another disadvantage of known supply chains 
networks. 

Thus, there exists a need in the art for a supply chain architecture which can 
remove the inefficiencies referenced above and thereby reduce the losses 
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incurred by both customers and suppliers in the sale and distribution of 
products. 



SUMMARY OF TEE INVENTION 

A supply chain network where customers, suppliers, logistics 
5 providers, carriers, and financial institutions are all connected to a centralized 
supply chain server The server receives forecasts from the customers detailiag 
the orders that the customers desire. These forecasts are analyzed by the supply 
chain server to ensure that they conform to contractual agreements and do not 
contain errors. The forecasts are also used to warn the suppliers of future 
10 demands so that the suppUers can anticipate demands and plan inventory 
accordingly. 

The supply chaia server checks with the suppliers to determine whether the 
forecasts can be fiilfilled by the suppliers. If the forecasts cannot be fulfilled by 
the suppliers, the supply chain server contacts customers and suppliers and 

15 attempts to either redistribute the customers* demands to different suppUers or 
request that customers alter their demands. When supply issues have been 
resolved, the customers' demands are sent to the suppliers in groups so that the 
suppUers need to prepare a smaUer number of large orders. 

The supply chaia server oversees and controls the processes 

20 involved in distributing the product from the suppUers to the customers 

including the generation of purchase orders and invoices. Customers pay the 
supply chain server and that payment is then forwarded to the appropriate 
suppUers and logistics providers. If a customer wishes to retum a product, the 
retum process is also overseen and controlled by the supply chain server. As 

25 customers, suppUers, and logistics providers all commimicate with the supply 
chain server, the novel architecture yields useful information not available in 



wo 01/52158 



PCT/USOl/01296 



-6- 

the prior art. This information includes, for example, customer demand 
propensities, supplier performance, etc. 

Since the supply chain server receives customer forecasts, an 
operator of the supply chain server can more confidently receive suppliers' 
5 products ahead of a designated schedule - thereby allowing a supplier to ship 
early to improve the supplier's accounting books. Additionally, the operator of 
the supply chain server can more confidently provide a customer with financing 
arrangements associated with the demanded products. This arrangement is 
because if the customer does not pay for the products as contracted, the operator 
10 can withhold shipment of fiiture products to the customer. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For the purpose of illustrating the invention, there is shown ia the 
drawings a form which is presently preferred, it being understood, however, that 
the invention is not limited to the precise arrangements and instrumentalities 
15. shown. 

Fig. 1 is a block diagram of a prior art supply chain architecture. 

Fig. 2 is a block diagram of a supply chain network in accordance 
with the invention. 

Fig. 3 is a block diagram illustrating the modules effectuating the 
20 supply chain network of Fig. 2. 

Fig. 4 is a diagram illustrating a Demand Capture and Validation 
process performed by an Order Management Module during a regular demand 
request in accordance with the invention. 

Fig. 5 is a diagram illustrating a Demand Capture and Validation 
25 process performed by the Order Management Module during an ad hoc demand 
request. 
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Fig. 6 is a diagram illustrating the processes performed by the 
Planning Module in accordance with the invention. 

Fig. 7 is a diagram illustrating an example of the flow of 
information during the Planning Module of Fig. 6. 
5 Fig. 8 is a diagram illustrating the processes perfomied during the 

Planning Module of Fig. 6 when customer demand exceeds supplier capacity. 

Fig. 9 is a diagram illustrating an example of the flow of 
infomiation during the Planning Module of Fig. 6 upon receipt of an ad hoc 
customer request. 

1 0 Fig. 1 OA is a diagram illustrating the processes of the 

Procurement Module in accordance with the invention. 

Fig. 1 OB is a diagram illustrating an error routine performed in the 
Procurement Module of Fig. lOA. 

Fig. 1 1 is a diagram showing a continuation of the processes 
1 5 performed in the Procurement Module of Fig. 1 OA, 

Fig. 12 is a diagram showing a continuation of the processes 
performed in the Procurement Module of Figs. lOA and 11. 

Fig. 13 is a diagram showing a continuation of the processes 
performed in the Procurement Module of Figs. lOA, 11 and 12. 
20 Fig. 14 is a diagram illustrating the processes performed by the 

Procurement Module when a customer desires to return an item procured 
through the supply chain network. 

Fig. 15 is diagram showing a continuation of the processes 
depicted in Fig. 14. 

25 Fig. 16 is a diagram illustrating the flow of information and 

products during a Fulfillment Module in accordance with the invention. 

Fig. 17 is a diagram illustrating the production of invoices 
performed by a Billing and Payment Module in accordance with the invention. 
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Fig. 18 is a diagram showing the payment of invoices during the 
Billing and Payment Module. 

Fig. 19 is a diagram illustrating types of information and 
corresponding time intervals provided by the supply chain network in 
5 accordance with the invention. 

Fig. 20 is a diagram illustrating the flow of title and payment for 
products in accordance with an embodiment of the invention. 

Fig. 21 is a diagram illustrating an altemative flow of title and 
payment for products in accordance with another embodiment of the invention. 
10 Fig. 22 is a diagram illustrating an embodiment of the 

architectural set up for the supply chain architecture in accordance with the 
invention. 

Fig. 23 is a diagram illustrating an embodiment of a supply chain 
server in accordance with the invention. 
15 Fig. 24 is a more detailed diagram illustrating the supply chain 

server environment for the supply chain server shown in Fig. 23. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

T General Overview 

In the following description, terms describing processes and 
20 hardware are used interchangeably eis it should be clear that the functions 

described could be implemented using many different forms of hardware, 

software or even manually. 

The invention creates a network which supports customers 

requesting the same or similar products. The customers using a supply chain 
25 network in accordance with the invention reaUze lower costs and increased 

flexibility even in changing supply demands. In one embodiment, the products 

received by customers are initially qualified by the customers first - in that the 
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products can be extensively tested by a customer before the product is 
"qualified" or permitted in the customer's manufacturing process. Once the 
product is qualified, a defined set of interactions occur in a particular sequence 
and at designated tunes that permit the supply chain to be managed and well 
5 synchronized between customer and suppUer. Such a well synchronized supply 
chain has minimal inventories and short reaction supply times. 

Referring to Fig, 2, there is shown a general overview of a supply 
chaiu network in accordance with the iavention. Supply chain network 70 
includes customers 72 of any size. Customers 72 each place orders with a 

10 supply chain server 74. Supply chain server 74 accumulates demand forecasts 
firom customers 72 who are using the same or similar products. These demands 
are then aggregated and supply chain server 74 determines the best method for 
distributing all the products requested fi"om any approved suppliers 76 to any 
requesting customers 72. 

1 5 Although supply chain server 74 will typically be comprised of a 

computer, it will be referred to throughout the description as an entity capable 
of entering into a contractual relationship. It should be understood that in such 
descriptions, the operator of the server will be the real party in the contract. It 
should also be understood that supply chain server 74 need not be implemented 

20 as a computer. 

Since the customer orders are aggregated by supply chain server 
74, suppliers 76 need to assemble a relatively smaller number of orders 
compared with the number of customers and shipment for the entire network of 
customers. In one embodiment the products are then picked up by a freight 

25 company as designated by a logistics provider 78 (hereinafter "3PL" - third 
party logistic provider) and taken to a location (which can be the same location 
as where the shipment was picked up) where instructions are provided by 
supply chain server 74 for the distribution of the products. These instructions 
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indicate how the order is to be broken down and re-assembled in the exact 
quantities required by the specific customers. Breaking down the order is called 
a cross-dock operation and is performed at a cross-dock point. Supply chain 
network 70 can work with any number of customers, suppliers and logistics 
5 providers. In another embodiment, the customer or the supplier point performs 
the activities ascribed to the Logistics Provider. 

By deciding later in the distribution process to whom and where 
products will be shipped yields maximum flexibility, minimum overall cycle 
time, and eliminates the costly need to manage a customer's order within the 

10 supplier's order management system. This is advantageous because order 
management costs can be quite substantial for suppliers managing large 
numbers of customers and large mmibers of different part types and numbers. 
The present invention provides economic advantages, as the cost of managing 
one order for one part is generally much higher than disassembling a larger 

15 order of many parts into specific quantities. 

After the products are disassembled, the orders of each individual 
customer may be shipped to their final destinations using conventional means 
and carriers. For large quantities of products coming firom many different 
suppliers and going to many different customer locations, the cross dock may 

20 be strategically located so as to minimize the overall shipping and handling 
costs. 

Referring to Fig. 3, the operations of supply chain network 70 can be broken up 
into five main modules: 

1) . Order Management 40 - collecting customer forecasts and 
25 determining if the requests are valid; 

2) Planning 42 - determining if customer demands exceed supply - 
and providing solutions if demand does exceed supply; 

3) Procurement 44 - execution of the purchasing process; 
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4) Fulfillment 46 - transporting the products from suppliers to 
customers; 

5) Billing and payment 48 - generation and payment of invoices. 
Although a typical customer demand will typically follow the 

5 order of the modules shown in Fig. 3, the Modules operate independently and 
sometimes concurrently as will be explained more fully below. For example, 
the Order Management for one day's demands may take place at the same time 
as the Fulfillment of a previous day's demands. Prior art supply chain systems 
handled many of these fimctions as completely independent events without 

10 communication between each functional module. For example, fulfillment was 
handled independently of supplier payments or even order management. In 
addition, information management refers to incorporated into each of these 
modules as would benefit its users. Information management refers to the 
accumulation of useful supply chain management information that is beneficial 

15 to customers and suppliers. 

The invention manages all these activities for many customers and 
many suppliers simultaneously. This enables the invention to perform these 
tasks more efficiently for all parties. To illustrate this point, consider a 
customer X who receives a large msh order requiring certain parts from 

20 suppliers A and B but neither supplier A nor B have the inventories to meet the 
needs of the customer. By handling many customer and supplier 

supply and demand requirements simultaneously, a supply chain architecture in 
accordance with the invention can determine that a supplier C has extra parts of 
the same type demanded and that another customer Y plans to use either 

25 supplier B or C for his needs. The supply chain server can then arrange for 
supplier C to ship extra parts required by customer Y so that supplier B can ship 
extra parts required by customer X. 
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In one embodiment, supply chain network 70 is implemented 
using a cadence where all transactions are linked to one another and performed 
on a regular basis. For example, all customers using supply chain network 70 
could order all parts within a certain commodity family on a given day of the 
5 week. This creates a large economy of scale in the fulfillment activities that is 
passed to users of the network. Frequently, production requirements are 
planned over the weekend thereby causing Monday to be a desirable day to start 
the Order Management cycle. As such, in one embodiment of the invention. 
Planning takes place on Monday night. Fulfillment of all parts on Tuesday, and 

10 Billing on Tuesday night. Some parts are used in very high volumes or are 
perishable. In accordance with the invention, these parts could be planned, 
ordered, and fiilfilled on a daily cadence even marked off in hours. In prior art 
techniques, many dates needed to be entered, tracked and changed according to 
the expected delivery status of the product ordered. This is a very costiy and 

15 time consuming task as the sequence of information, products, and currency can 
change dependiQg upon the needs of the specific customers, suppliers and 
logistics providers that are using the network. 

Product usage by customers is often determined by an of ERP 
computer system on a weekly basis, the supply chain network in accordance 

20 with the invention realizes order, planning, and delivery times that cumulatively 
considerably less than one week. This system enables customers to 
significantly vary production plans at the end of the work and still be able to 
receive the necessary parts without using a large quantity and assortment of 
parts in a costly inventory. This also eliminates the need to manage a multitude 

25 of dates ia the ERP system. 

The individual modules will now be explained in detail with 
continuing reference to Fig. 3. Note again that portions of these modules 
operate concuirentiy. 
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n. Order Management 

The Order Management Module provides an environment where 
supply chain server 74 directly interacts with customers 72. This Module 
includes the processes required to capture customer demand and the validation 
5 and approval required to process that customer demand. 

Customers 72 submit their demand for desired products to supply chain server 
74 in multiple ways. For example, in a preferred embodiment, customers 72 
submit their requests using a thirteen week forecast, week 0 daily callouts, and 
ad hoc requests. Each week, customers 72 submit a thirteen week forecast for 

10 each of the Planning/Ship-to locations specified in their contract with supply 
chain server 74. For high volume and volatile commodities such as DRAMs 
(dynamic random access memories), customers 72 also communicate their week 
0 (i.e. current week) demand by sending daily callouts. In addition, customers 
72 also have the abihty to submit any unforecasted demand to supply chain 

15 server 74 by sending an ad hoc request. Such an ad hoc request is an order that 
no supplier has been prepared to receive as it was not forecasted or was not 
within forecasting tolerances defined in contractual arrangements between 
supphers and customers or defined by contracts for the network. An ad hoc 
order is therefore more likely to be unfulfilled within a standard cadence 

20 without intervention from human Planners - discussed below. 

Once customer demand is received, it is vahdated by the Order Management 
Module against contract terms and details outlined during an initial customer 
set-up process. This vahdation may include verifying that the forecast is 
complete, ensuring that every part number exists in the supply chain server 

25 system, and/or that all required information is complete and accurate. If a 
customer demand is invalid, abnormal, or incomplete, supply chain server 74 
notifies the customer on a exception basis that something is wrong with their 
request and a resolution process is initiated. Examples of the analysis that the 
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Order Management Module may perfoim and thereby improve the validity of 
the forecasts received include, but are not limited to: 

identifying major shifts relative to previous weeks' forecasts; 
identifying major cumulative shifts in buying patterns; and 
5 - identifying requests outside agreed upon capacities. 

Supply chain server 74 or Planners can also check supply and 
demand requirements relative to known customer events such as start-up, 
end-of-run, and plant shutdowns. Planners are employees of the operator 
supply chain server 74 who intervene when supply chain server 74 is unable to 

10 fiilfill all the unconstrained demand with available supply as is described below. 
Planners contact customers, using for example, e-mail, and suppliers and 
suggest adjustments to their respective production plans to create a better 
supply and demand balance for all parties. Server 74 notifies Planners of these 
conditions using exception reporting. Planners can use a Planner Supply Tool 

15 (discussed below) which provides valuable and xmique information produced by 
supply chain server 74. Planners can thus make better suggestions on how 
supply and demand can be balanced than that which could be performed by a 
customer or supplier on their own. 

In response to an invalid demand, supply chain server 74 sends 

20 e-mail or other message alerts to all potentially impacted parties, including the 
employees of the supply chain server (i.e. Planners). Such message alerts can 
include, but are not limited to, issuing "Red light" or "Yellow light" alerts to 
depict relative importance and immediacy of attention required. Examples of 
such alerts are shovm below. Clearly other criteria could be used to produce an 

25 alert message. 
Nomenclature 

Nab = Forecast made on week *a' for quantity to be delivered on week 'b* where 
b>a 
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Kc = Capacity available on week c 

Weeks 0-13 Abnormalities: 
Yellow lights 

For all: a, a-1, a-2, . . a-13 
5 .8<E Nab/E Na-lb-1 < 1.2, sunimedfor 0 #b -a#13 

(no more than 20% change in total requirements from week to week) 
and 

.75 < E Nab/max(E Nab), summed for 0#b - a #13 
(no more than 25% upside volatility over the past 13 weeks) 
10 E Na+lb+l/min(E Nab) < 1.25, summed for 0#b- a #13 
(no more than 25% downside volatility over the past 13 weeks) 

Weeks 9-13 Abnormalities: 
Yellow lights 

Forb = a+9, lOA, 11, 12, 13 
15 ,8< Nab/ Na-lb.Kl.2 

(no more than 20% change in requirements from week to week) 

Weeks 7, 8, 9 Abnormahties: 
Yellow lights 
Forb-a+7, 8,9 
20 .8< Nab/ Na-lb-l< 1.2 

(no more than 20% change in requirements from week to week) 

Red Ught 
Nab>Kb 

(no week's requirement exceed capacity) 
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Weeks 0-6 Abnormalities: 
Yellow lights 

.8<E Nab/E Na-lb-1 < 1.2, summed for 0#b -a #6 
(no more than 20% change in total requirements from week to week) 
5 and 

Forb = a+0, 1,2, .,6 
.9< Nab/ Na-lb-Kl.l 

(no more than 10% change in requirements from week to week) 
Red lights 
10 Nab#Kb 

(no week's requirement exceed capacity) 
or 

J< E Nab/E Na-6b<L05, summed for 0#b-a# 6 
(no more than 30% unused requirement compared to what was started in 
15 production 6 weeks ago, and no more than 5% over) 

Weeks 0, 1, 2 Abnormalities: 
Red lights 
Forb = a + 0, 1,2 
.95 < Nab/ Na-lb-l<L05 
20 (no more than 5% change in requirements from week to week) 

Customer credit history and approval may also be integrated as 
part of the Order Management Module. After demand has been vaUdated and 
the credit of the customer has been checked, the demand is sent to the Planning 
Module. Demand for customers on credit hold can be sent to a 

25 suspend file for action by an Account Manager. 



wo 01/52158 



PCT/USOl/01296 



-17- 

An exemplary embodiment of the Order Management module will 
now be explained. Referring to Fig. 4, there is shown a demand capture and 
validation process performed by the Order Management module during a 
regular demand schedule. During a regular demand schedule, supply chain 
5 server 74 receives 204 a thirteen week customer forecast 200 and week 0 daily 
callouts 202 from customers 72. The forecasts may be from a plurality of 
customers or even from a plurahty of sources within a single customer. 
Receiving circuit 204 may capture customer demands through, for example, an 
EDI (Electronic Data Interchange) forecast, an e-mail (e.g. with an EXCEL 

10 spreadsheet), an EDI purchase order ("PO") or through XML (extensive markup 
language) communication. Receiving circuit 204 may also capture specific 
services which may not be specified in the customer contract. For example, 
expedited delivery, special labeling, packaging, etc., all may be captured. 
Supply chain server 74 converts 206 the customer demands 200, 202 into a 

1 5 standard format used by supply chain server 74 to analyze the customer 
demands. If there are problems with conversion 206, an error routine 208 is 
performed to cure all technical difficulties. In a preferred embodiment, all such 
technical difficulties should be resolved by the end of the business day. 
Thereafter, a delay circuit 210 ensures all the converted demands are stored and 

20 the required ftmctional validations are performed by the end of the business 
day. Such a delay allows server 74 to accumulate demands (200, 202) for all 
customers. 

A collect customer information circuit 212 compares the converted customer's 
demands with the corresponding customer contract 214 and with current 
25 customer product information 2 1 3 regarding the customer's products. 
Information 213 includes, for example, approved suppliers, specification 
revisions levels, etc. 
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A validation circuit 216 detennines whether the converted demands are valid 
VaUdation circuit 216 detects, for example, whether the demanding customer is 
actually a customer of supply chain network 70. Validation circuit 216 also 
detects whether customer forecast 200 is complete in that there is one forecast 
5 for every planning/ship-to location and part number combination, and that every 
part number has a specified quantity. Finally, validation chrcuit 216 may verify 
that the requested part number relates to a valid part contracted between 
customer 72 and the entity running supply chain server 74, 

If validation circuit 216 determines that a particular customer 

1 0 demand is not valid, an error routine 21 8 is performed where a notification is 
sent to an Account Manager to resolve the outstanding issues. The Account 
manager is used to maintain a current standing for all customers by evaluating 
their payment history. Supply chain server 74 then sends the customer 72 an 
exception notification to inform the customer that the demand was incomplete 

15 in some way. The exception notification itself is stored in a suspend file until it 
is acted upon. If the customer demand is valid, supply chain server 74 checks 
220 the credit status of the customer by referring to the customer's credit history 
222. If the customer's credit standing is approved at 224, supply chain server 
74 branches to the Planning Module (shown m Fig. 8). If the credit standing is 

20 not approved at 224, an error routine 226 is initiated where the Planner, the 
Accoimt Manager and the Credit Manager attempt to form a resolution of the 
problem. Late payments or delinquent accounts are monitored by the Credit 
Manager. All customer demands with denied credit are stored in a credit 
suspend file. If a customer demand is denied because of bad credit, a 

25 notification is sent to the Account Manager, the Credit Manager, and the 

Planner informing them of the customer's intent to buy. In such a situation, the 
Planner can view the customer's demand but is not obligated to actually 
implement the planning until the credit issue is resolved. 
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For an ad hoc demand, the process flow of the Order Management 
Module is as shown in Fig. 5. Referring to Fig. 5, as with a regular customer 
forecast of Fig. 4, supply chain server 74 receives 230 an ad hoc demand 232 
and converts 234 ad hoc demand 232 into a standard format as explained above. 
5 Again ad hoc demand 232 can be captured via e-mail with, for example, an 
EXCEL spreadsheet or an EDI PO. Additional services, which were not 
specified in the customer contract, are also captured - such as expedited 
delivery, special labeling or packaging. Unlike with a regular customer 
forecast, a field is established (not shown) to identify the ad hoc demand to 

1 0 track order billing information. This field may optionally be used to generate 
an additional charge for ad hoc orders. If there are problems in converting the 
customer demand to a standard format, an error routine 236 is performed to cure 
all technical difficulties. In a preferred embodiment, all such technical 
difficulties should be resolved by the end of the business day. 

15 Thereafter, a delay circuit 238 ensures all the converted demands 

are stored and the required functional vahdations are performed by the end of 
the business day. A collect customer information circuit 240 performs the 
validation by compiling the converted customer's demands and comparing them 
with customer contract 214 and customer product ioformation 213. 

20 A validation circuit 244 determines whether the converted 

demands are valid. Validation circuit 244 detects, for example, whether the 
demanding customer is actually a customer of supply chain server 70. 
VaUdation circuit 244 also detects whether the requested part number is a vahd 
part contracted for between customer 72 and supply chain server 74, Unlike 

25 with a normal forecasted demand, no validation is necessary to determine if ad 
hoc demand 232 is complete as it is an unforecasted demand and can include 
either one or more customer part numbers. 
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If validation circuit 244 deteraiines that the customer demand is 
not valid, an error routine 246 is perfomied where a notification is sent to the 
Account Manager to resolve the outstanding issues. Supply chain server 74 
then sends customer 72 an exception notification to inform the customer that the 
5 demand was incomplete in some way. The exception notification itself is stored 
in a suspend file. If the customer demand is valid, supply chain server 74 checks 
248 the credit status of the customer by referring to the customer's credit history 
250. If the customer's credit standing is approved at 252, supply chain server 
74 branches to the Planning Module. If the credit standing is not approved at 

10 252, an error routine 254 is initiated where the Planner, the Account Manager 
and the Credit Manager attempt to fomi a resolution of the problem. All 
customer demands with denied credit are stored in a credit suspend file. If a 
customer demand is denied because of bad credit, a notification is sent to the 
Account Manager, the Credit Manager, and the Planner informing them of the 

1 5 customer's intent to buy. 

In this way, the Order Management Module of supply cham 
server 74 uses a forecast system to replace the purchase order system that was 
used in the prior art. In prior art supply systems, suppliers did not see forecasts 
and could not determine whether a forecast was contrary to a contractual 

20 agreement or whether there was an undesired error in the forecast. The supplier 
only saw what a particular customer gave the supplier. Even if the supplier 
used an MRP system, MRP demands frequently vary significantly and suppliers 
did not have the ability to review these demands to ascertain unusual or 
imexpected requests. SuppHers thus often used replenishment algorithms to 

25 replenish their stock as they were never certain as to the expected amount of 
depletion of the stock. 

The invention overcomes these problems by reviewmg the 
customer forecasts for consistency with contractual agreements and with prior 
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forecasts. The invention thereby produces continued delivery and performance 
thus reducing the amount of undesired scrap material produced when suppliers 
have excess inventory. Suppliers benefit from the supply chain architecture 
because demand volatility is minimized. This is due to the accumulation of the 
5 demand forecasts and filtration systems reviewing the demands. Suppliers can 
also replenish their inventories with more certainty as they are now given a 
forecast of customer demands from many customers a few weeks in advance. 
In high volatility demand industries such as demands for electronic 
components, prior art supply chains could not work based upon customer 

10 forecasts because a 50% change in demand from one week to the next was 
possible. As prior art supply chains took too long to deliver a product to a 
customer, they could not keep up with these highly volatile demands. However, 
the supply chain architecture of the invention enables much quicker delivery 
(e.g. within one week) so that forecasted based customer demands are possible. 

15 The Order Management Module also provides customers with the 

ability to check the status of an order. A typical customer may be interested in 
knowing exactly what product he is getting and when that product is on its way. 
Listed below are some typical events that may be tracked by supply chain 
server 74. In each of these notifications, information may be sent to supply 

20 chain server 74 so that an extranet of supply chain server 74 (the hardware of 
supply cham server 74 is discussed more completely below) can be updated 
accordingly. 

Order release notification 

An order release notification provided by the Planning Module 
25 may be generated after a specific order is released to the supplier 76 or suppHers 
(one customer order may be fiilfiUed by several suppUers). This event may be 
used to inform customer 72 that their order has been reviewed and passed on to 
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the suppliers who are responsible for fulfilling the order. The Planning Module 
then updates the Extranet at the time of forecast release to the Suppliers. 
Shipment pick up notification 

A shipment pick up notification may be sent to supply chain 
5 server 74 by 3PL 78, radicating that a carrier has picked up a product from a 
given set of suppUers 76. This event provides supply chain server 74 with 
information used to monitor suppUer 76 and 3PL 78 performance. This event 
also captures information that can be compared against the supply plan to 
identify discrepancies between expected and actual suppher shipments. 

1 0 Cross-dock arrival notification 

A cross-dock arrival notification may be sent to supply chain 
server 74 by 3PL 78, indicating that a product has arrived at the cross-dock. 
This event also provides supply chain server 74 with information to 
contiQUOUsly 3PL performance. 

1 5 Shipment notification 

A shipment notification may be sent to supply chain server 74 by 
3PL 78, indicating that the order is on its way to customer 72. 

Customs-In notification 

When applicable, a customs-in notification may be sent to supply chain server 
20 74 by 3PL 78, indicating that a product is in customs. 

Customs-Out notification 

When applicable, a customs-out notification can be sent to supply 
chain server 74 by 3PL 78, indicating that a product is out of customs. 
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Proof of Delivery (POD) notification 

A POD and final notification can be sent to supply chain server 74 
by 3PL 78, indicating that a customer shipment has been delivered to the 
specified locations. 

5 Flow Monitoring 

Server 74 can monitor the flow of products through a bottleneck 
or pinch point in the supply chain. For example, it may be difficult to book a 
flight to a particular destination or to make it through customs at a particular 
city. A notification may be sent any time parts are bumped fi-om a flight or 
10 when the parts make a crowded flight. A notification can be sent to a supplier's 
production line as well. 

in. Planning 

The supply chain network Planning Module is responsible for 
matching a source of suppliers 76 to meet customer demand and for initiating 

15 the Fulfilhnent Module. This capabiUty also serves as a vehicle to capture vital, 
real-time data on: industry trends, commodity/product trends, customer forecast 
accuracy, and suppHer performance. This data constitutes the basis for many of 
the daily management reports and additional expert services that supply chain 
network 70 offers to its suppliers 76 and customers 72. 

20 The long term planning fimction of the supply chain network 70 

may be performed manually since it does not need to be performed on short 
notice or with high fi:equency . Short term planning, within manufacturing and 
materials procurement lead times, however, should be automated as it is 
performed very firequentiy. The results of the short term planning should then 

25 be executable within a matter of hours or minutes, with great accuracy. 
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Otherwise, the plans may no longer apply to the fast paced change characteristic 
of many markets today. 

The Planning Module may be triggered by any of a multiple 
number of events. An exemplary embodiment of these events includes the 
5 receipt of a customer's planning period (e.g., quarterly or thirteen week) 

forecast, the receipt of a daily forecast for a week 0 demand, the receipt of an ad 
hoc order (unforecasted demand) from a customer, a supplier's de-commit at the 
time of shipment (short shipment), or the delayed replacement of retumed parts. 
All of these possibilities will be discussed below. In all of these circiraistances, 

10 the process depends on multiple inputs such as: demand information from the 
customer, customer preferences for supphers (if any), current capacity 
information from the suppHer, tables cross-referencing customer parts to other 
similar parts used within supply chain network 70, and tables cross-referencing 
part numbers used in supply chain network 70 to supplier part numbers. An 

15 example of such tables can be found in co-pending appHcation serial number 
09/704,643 ffled on November 2, 2000 for a SYSTEM AND METHOD FOR 
GENERATING A CROSS REFERENCE GUIDE, tiie entirety of which is 
hereby incorporated by reference. 

As discussed above, in a preferred embodiment, each week, 

20 customers 72 submit a thirteen week demand forecast for each of the parts 
customers 72 will need over that time period. In the Planning Module, supply 
chain server 74 manages these forecasts and the demands are consolidated, 
translated into supplier part numbers, and transformed into specific supplier 
requirements. Supply chain server 74 achieves this transformation via demand 

25 aggregation, rough cut capacity matching and supply plan optimization. Server 
74 may also extrapolate forecasts based on expected demand and historical data 
from customers 72. 
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Supply chain server 74 performs aggregation by accumulating 
demand for products made using the same or similar supplier manufacturing 
processes. Since customers, and often supphers, like to assign different part 
numbers to the same or similar products, aggregation by trying to match 
5 identical part nimibers is generally ineffective. However, as suppliers aggregate 
customer orders into MPUs, or Master Planning Units (sometimes also referred 
to as Master Planning Families), to schedule their internal production faciUties, 
supply chain server 74 uses these same suppUer defined MPUs to perform its 
aggregation. 

10 Supply chain server 74 performs rough cut capacity matching, by first assigning 
aggregated demand to particular suppliers that customers 72 have determined as 
their preferred suppliers. Each customer 72 will have its own definition of a 
preferred supplier and supply chain server 74 retains this information in its data 
banks for each customer part number. Supply chain server 74 tests to see if this 

15 default assignment of demand to each preferred suppher falls within the supply 
capacity constraints given by suppUers 76. Any demand on a given supplier in 
excess of the supplier's capacity constraints is re-assigned by supply chain 
server 74 to another suppher, based on customer second-choice preferences or 
other algorithms the network uses. Supply chain server 74 uses this iterative 

20 approach to determine a rough cut allocation of demand to the available supply. 

Supply chain Planners may be used to review the rough cut 
capacity match to determine if any intervention is required to perform supply 
chain optimization. Since supply and demand of many types of components are 
very volatile and change on very short notice, Planners may wish to intervene to 

25 make manual adjustments to the rough cut capacity match. As an example of 
such an intervention, often suppliers of leading edge components suffer firom 
periodic yield problems where they cannot produce their stated capacity for 
some period of time. In such an instance, supply chain server 74 will be 
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informed by a supplier, through an electronic message, telephone call, or an 
ASN (advanced ship notice), that fewer parts than expected had actually been 
shipped. Supply chain Planners then, using extensive information available to 
them on the Supply chain network 70, decide how best to re-allocate demand 
5 products, either by manually over-riding the system, or by entering new 
parameters into the system. This results in some demand reduction at the 
impacted supplier and increased demand at other suppliers. Thus, supply chain 
network 70 can be controlled so the Planner can feel more secure that all the 
supply chain network's customers will receive their parts as expected. 

10 Similarly, it sometimes may be in the customer's best interest to allocate some 
demand to a non-preferred supplier in order to foster a more competitive 
market-place, and the supply chain Planners may shift some demand to 
optimize supply chain network 70 in this way. 

The result of supply chain optimization is a supply plan that 

15 effectively meets all customer demand within the suppliers' capacity constraints. 
The demand/supply matching process may be executed on a daily basis during 
week 0 for certain volatile commodities (i.e., DRAM). After confirming their 
ability to support this plan, suppliers are ready to execute the week 0 demand 
and initiate the fiilfilhnent process in the Fulfilhnent Module. Suppliers may 

20 also be required to follow defined production or inventory management 
protocols relating to demanded products. 

On occasion, a customer may place an ad hoc order with supply 
chain server 74 for quantities or material not originally included in the 
customer's weekly forecast. In such an event, capacity availability to support 

25 the new demand is investigated by Planners. The Planner identifies, when 
possible, source(s) for the new request and initiates the fulfillment process in 
the Fulfillment Module. 
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If a supplier 76 is unable to meet its commitment (short shipment), the Planner 
may act as an intermediary between the customer and supplier to resolve the 
situation. If necessary, the Plamier wiU identify alternate sources of supply and 
restart the Fulfillment Module. If material is returned to the supplier and 
5 replacement parts are needed at a later date, the Planner adjusts future demand 
to reflect the need for the replacement parts. 

The transactional nature of these processes provides supply chain 
network 74 with information critical to some of the value added services it may 
offer. This infomiation includes: customer/industry buying patterns, customer 

10 forecast accuracy, supplier performance, and product transitions. Such 
information may be made available as is discussed in the Information 
Management section below. 

Referring to Fig. 6, there is shown the flow of information during 
operation of the Planning Module. A plurality of customers 72 (two are shown 

15 in the figure), a plurality of suppliers 76 (two are also shown), a 3PL 78 and a 
carrier 96 are comiected to supply chain server 74. The Planning Module 
begins with suppliers 76 sending previous weeks* capacity exceptions 98 
regarding supply shortfalls and customers 72 sending forecasts 100 to supply 
chain server 74. Forecasts 100 are adjusted to take into account previous weeks* 

20 returns which were not immediately replaced and not yet reflected in the 

forecast. (See the discussion in the Procurement Module below). Supply chain 
server 74 receives these inputs 98, 100 and performs a validation 102 of the 
demands made by customers 72 in forecasts 100. 

As discussed above in the description of the Order Management 

25 Module, supply chain server 74 performs an evaluation 104 of the variability of 
forecasts 100 and issues exception notifications 106 when the variability of the 
forecasts do not conform to defined parameters. The part nimibers requested by 
customers 72 are converted 108 to correspondiag supply chain network part 
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numbers. Supply chain server 74 evaluates 1 10 the demand variability of 
supply chain network part numbers. As with customer evaluation 104, supply 
chain server 74 determines the overall demand variability. This calculation is 
useful in that, even though each individual customer may avoid exceeding 
5 allowed tolerances, the aggregation of all customer requests may exceed total 
supply especially if many customers order close to their allowed limits. Such 
ordering may cause overall depletion of suppliers' products which may take 
some time to restore. The supply chain network part numbers are then 
converted 1 12 to corresponding suppUer part nimibers, 

10 The capacity of suppliers 76 is validated 1 14 to determine if there 

are any capacity issues involved with the forecasts 100 of customers 72. As is 
indicated at 1 15, this process starts with the current week 0 demand and iterates 
through the week 12 demand. Any capacity issues are resolved 1 16 by sending 
a notification 118 to suppliers 76 and a notification 120 to customers 72, 

15 Customers 72 also receive an abort code 122 which enables customers 72 to 
send an optional abort 124 of part or all of forecast 100. Supply chain server 74 
then resolves all demand issues 126 with suppliers 76 and control branches to 
Procurement Module 44 of Figure lOA. Such an abort would then be displayed 
if the customer accesses its account through supply chain server 74 so that the 

20 customer knows that the order for the particular parts was aborted. These 
processes will now be explained in detail by way of an example. 

Referring now to Fig. 7, there is shovm the processes performed 
by supply chaia server 74 during a normal planning scenario. In the Planning 
Module, supply chain server 74 receives information from the Order 

25 Management Module (discussed above) regarding customer forecasts. Supply 
chain server 74 then consolidates 130 all validated customer requests. This 
consolidation includes grouping all customer forecasts into one large demand 
file (not shown) based on customer part and number. The validation itself was 
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described in the Order Management module. Briefly, the validation includes 
determining whether the customer demand is invalid under contract terms, 
incomplete, or abnormal. If there are problems with the validation, an error 
process 132 is performed. Error process 132 is also explained more fidly 
5 above. In brief, supply chain server 74 communicates with the customer having 
the validation problem to imderstand and resolve demand changes. This may 
include adjusting the demand quantities for a specific part number. Any 
changes are then reflected in an adjusted forecast. 

The consolidated demand file is then analyzed 134 to identify corresponding 

10 supply chain network part numbers and suggested suppliers to provide the parts 
corresponding to the supply chain network part numbers. The supplier 
identification is based upon contracts negotiated with the customer as discussed 
above. In analj^ation 134, a unique identifier is assigned to represent the 
demand for each part from each customer during each week. These identifiers 

15 are used to create an audit trail for each demand. Analyzation 134 also evaluates 
forecasts 100 fi'om the previous week's demand to determine exception 
conditions - as was discussed more fully above in the description of the Order 
Management Module. 

Supply chain server 74 then converts 136 the supply chain 

20 network part nxmaber of the consolidated demand file into corresponding 
supplier part numbers. This conversion can be done using the customer part 
number as well. The consolidated demand file is then aggregated 138 to 
produce supplier MPUs based upon contractual factors between supply chain 
server 74 and suppUers 76. The consolidated demand file is then validated 142 

25 based upon the capacity of suppUers 76 and contractual provisions between 
supply chain network 74 and suppliers 76. These contractual provisions relate 
to any contractual capacity or supplier freeze horizons which may be enabled 
based upon the consolidated demand file. Finally, supply chain server 74 
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queries 144 whether the aggregated customer demand is greater than the 
supplier capacity. Supplier capacity may be determined firom data supplied by 
suppUers to server 74 or by suppliers 76 allowing access to their respective 
databases by server 74. If the demand is not greater than the capacity, then 
5 supply chain server 74 branches to step 330 explained with reference to Fig. 
lOA. If the demand is greater than the capacity, then supply chain server 74 
branches to a constrained supply planning routine 148 as is shown in Fig. 8. 

Referring to Fig. 8, constrained supply planning routine 148 iHrst 
redistributes 150 the customer demand in an attempt to ensure that there is no 

10 resultant unbalance between demand and supply. This redistributing is 
performed using an iterative process and a Planner using the Planner Tool 
(explained below with reference to Fig. 24) to determine altemate sources of 
supply in Kght of the suppUers' capacity and contractual frozen horizons. 
Supply chain server 74 then queries 152 whether the new resultant demand is 

15 greater than the suppliers' capacity. Again, if the demand is not greater than the 
capacity, supply chain server 74 branches to 330 in the Procurement Module, 
Otherwise, supply chain server 74 branches to supplier intervention 154. At 
suppUer intervention 154, supply chain server 74 communicates with supphers 
76 to ascertain the situation causing the suppUer's capacity to not equal the 

20 demand (e.g. raw material constraints or burst capacity issues) and evaluates 
possible altematives (e.g. the potential to build ahead or store for future 
capacity increases). This may produce a new supplier capacity. 

After contacting the suppUer in suppher intervention 154, supply 
chain server 74 queries 156 whether the new capacity is less than the customers' 

25 demand. Again, if the demand is not greater than the capacity, supply chain 
server 74 branches to 330 in the Procurement Module. Otherwise, supply chain 
server 74 branches to customer intervention 158. In customer intervention 158, 
supply chain server 74 communicates with customers 72 to ascertain any 
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possible customer flexibility (e.g. part substitutions, early or postponed 
delivery) to thereby produce a new customer demand. After contacting the 
customer at customer intervention 158, supply chain server 74 queries 160 
whether the new customer demand is greater than the suppliers' capacity. Again, 
5 if the demand is not greater than the capacity, supply chain server 74 branches 
to 330 in the Procurement Module. Otherwise, supply cham server 74 branches 
to an allocate supply routine 162. 

In allocate supply routine 162, the parts which actually are 
available from suppliers ("constrained parts") are allocated equally among the 

10 demanding customers and the forecasts of the customers are altered 

accordingly. In such an event, all demanding customers may receive an equal 
amount of the constrained parts, or the demanding customers may receive a pro 
rata share of the constrained parts based upon how many parts a particular 
customer requested in relation to how many parts other customers requested, 

15 Thereafter, supply chain server 70 branches to 330 in the Procurement Module. 

Aside from the normal planning scenario performed by supply 
chain server 74 in response to customer forecasts, as was detailed in Figs, 7 and 
8, the Planning Module can also process ad hoc customer demands. Referring 
to Fig. 9, there is shown the processes performed by supply chain server 74 in 

20 response to an ad hoc demand from customers. As with a typical order, supply 
chain server 74 receives a customer demand file from the Order Management 
Module. The demand file is then analyzed 166 to identify corresponding supply 
chain server supply numbers and suggested suppliers to provide the parts 
corresponding to the supply chain server supply numbers. The supplier 

25 identification is based upon contracts negotiated with the customer regarding 
preferred suppHers as was explained above. In analyzation 166, a unique 
identifier is assigned to represent the demand for each part from each customer 
during each week. 



wo 01/52158 



PCTAJS61/01296 



-32- 

Supply chain server 74 then converts 168 the supply chain server 
supply number of the demand file into corresponding suppher part numbers. 
This conversion can be done using the customer part number as well. 
Thereafter, in an identification circuit 170, supply chain server 74 
5 communicates with suppliers 76 and identifies various suppliers who may be 
able to provide an alternate supply for the ad hoc demand. 

Thereafter, supply chain server 74 modifies 172 week 0 supply 
forecasts to produce a modified forecast 178 that reflects new quantities for 
both suppliers and customers. The modified week 0 forecast is also sent to the 

10 Procurement Module discussed below. Supply chain server 74 sends 174 
modified forecasts 178 to suppliers along with a unique identifier assigned to 
represent a specific week's demand for each suppHer - similar to a purchase 
order nimiber. Finally, supply chain server 74 sends 176 documents 180 to 3PL 
78 including pickup and deUvery instructions for the ad hoc demand. The ad 

15 hoc demand orders will be sent directly to the customer and will generally not 
be sent through the cross dock described below. 

Thus, by receivmg and processing customer forecasts fi:om a 
plurality of customers, and evaluating these forecasts with respect to an 
aggregation of suppliers' capacities, the Planning Module can produce a more 

20 effective and usefiil supply plan than that available in the prior art. Moreover, 
as the network is in contact with a plurality of suppliers, the Planning Module 
can shift allocation of customers' demands among supphers to ensure that these 
demands are satisfied. 

IV. Procurement 

25 The Procurement Module executes the purchasing process. The 

focus of this fimction is on the purchase-to-pay cycle, including validation of 
the accuracy and timeliness of the order fulfillment process (the Fulfillment 
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Module will be discussed more completely below). Additional areas covered 
by Procurement include communicating the supply order to suppliers (data 
interface) and reverse logistics. 

Reverse Logistics is the process of moving products from their 
5 typical final destination to another point, for the purpose of capturing value 
otherwise unavailable, or for the proper disposal of the products. The following 
is a description of a preferred embodiment of the Procurement Process. 
Supply chain server 74, at the completion of the Planning Module, transmits a 
supply plan (including the week 0 demand) to supplier 76 via EDI, Web, email 

10 or other means. After supplier 76 executes the supply plan and 3PL 78 picks up 
the shipments, supplier 76 transmits an ASN (Advanced Ship Notice) to supply 
chain server 74. Each ASN typically includes one line item and is received 
electronically, containing all the necessary data agreed upon during the contract 
negotiation process. The ASNs are validated against the supply plan, and 

1 5 exceptions are resolved by the planner. Valid ASNs are used to generate 

purchase orders (there is generally a one-to-one relationship between ASNs and 
purchase orders; all line items are identified using the supplier part number) and 
cross dock instructions (which will be transmitted to the 3PL). In parallel, a 
receipt is created in an ERP system. Unlike prior art supply chains, the 

20 invention uses a suppher ASN to trigger the generation of a purchase order and 
a receipt notice indicating possession of the demanded part. This reduces a large 
number of steps performed in prior art systems because demand is conveyed to 
suppliers which is more likely to be fulfilled as it is based upon a forecast and 
not a purchase order. 

25 All payments received from customers during each day are Usted 

and consoUdated by supply chain server 74 for each supplier 76. If payment for 
a specific order has been received from customer 72 via EFT (Electronic Funds 
Transfer), supply chain server 74 uploads the payment files to a bank and 
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supplier 76 is paid (e.g., once per day). The release of payment information 
automatically updates the ERP. Additionally, the bank sends a confirmation to 
supply chain server 74 showing the payment information. If the payment is to 
be made via check, a remittance advice notice and the check are printed and 
5 sent to the suppUer. 

If a customer decides they would like to return materials procured through 
supply chain network 70, the customer contacts supply chain server 74 to obtain 
a return authorization. Supply chain server 74 includes pre-authorized return 
authorizations firom suppUers 76, and agreed upon terms for accepting retums. 

10 The supply chain server sends customer 72 the authorization, and sends a copy 
to supplier 76. If supplier 76 has an established retums process, supply chain 
server 74 will send customer 72 return instmctions. Once the supply chain 
server has the POD (Proof of Dehvery) from the suppher's carrier 96, supply 
chain server 74 will debit the suppUer's account and issue a credit to the 

15 customer. Any credits or debits are first applied to any open invoices from the 
suppUer, 

If the Supplier does not have an established retums process, once 
the authorizations are in place, supply chain server 74 sends pick-up 
instmctions to 3PL 78 if necessary. A determination must be made (1) whether 

20 the supplier has replacement parts in inventory and (2) whether the customer 
needs the replacements immediately or if the replacement parts demand can be 
added to the existing forecast. If the customer needs replacement parts 
immediately, the suppUer's available inventory is the preferred source. If no 
inventory is available, the replacement parts should be built and delivered to the 

25 customer on an expedited basis. If the replacement parts are to be added to the 
existing forecast, the planning process continues with the additional demand 
incorporated into the next thirteen week forecast (see Planning Module 
description). Again, once supply chain server 74 has received the POD from 
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3PL 78, supply chain server 74 will debit the supplier's account and issue a 
credit to the customer. Any credits or debits are first applied to any open 
invoices form the supplier, and then to the supplier account (to any open 
invoices). These processes will now be explained by way of example. 
5 Referring to Fig. lOA, there is shown the flow of information 

during the Procurement Module in accordance with the invention. After supply 
chain server 74 completes the operations involved in the Planning Module, tibie 
week 0 (or current week) supply demand is sent to the appropriate suppUer 76. 
SuppUer 76 executes 330 the week 0 demand, issues a supplier ASN 332 and 

10 sends ASN 332 to supply chain server 74. Supply chain servf;^ 74 receives 
suppher ASN 332 at 334. In general only one line item is included in each 
ASN 332. The ASN information itselfis in the supplier's part number. If the 
suppher's ASN accuracy percentage is poor, or the supplier cannot send ASNs, 
a packing shp is used instead. 

15 Supply chain server 74 validates 336 ASN 332 against a supply 

plan 338 generated by supply chain server 74 in response to customer forecasts. 
If the ASNs do not match supply plan 338 at 340, indicating that what was 
delivered by the supplier did not match what was ordered from the supplier, an 
error routine 342 is implemented and suppliers 76 are notified. In such an 

20 event, supply chain server 74 will have contractual options to, e.g., cancel the 
balance of the partial shipment immediately, return shipment, etc. Otherwise, 
supply chain server 74 branches to step 344 shown in Fig. 11. 

Referring to Fig. lOB, there is shown an example of error routine 
342 in accordance with the invention. St^ply chain server 74 sends 460 an 

25 exception notification 462 to supplier 76 alerting suppHer 76 of the 

nonconforming shipment. Thereafter, supply chain server 74 determines 
whether the comparison of ASN 332 and supply plan 338 results in an 
over-shipment or a short-shipment - outside of predetermined tolerances. 
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If the comparison yields an over-shipment, control branches to 
step 466 where supply chain server 74 determines the disposition of the excess 
materials involved in the over-shipment. This is performed by having the 
Planner discuss the situation with supplier 76 and relevant customers 72 to 
5 determine the appropriate disposition of the excess materials. Thereafter, 
supply chain server 74 executes 470 the resultant disposition plan and then 
branches to step 344 shown ui Fig. 1 1. Examples of the dispositions include 
returning excess material to the supplier, shipping the additional material to the 
customer (and adjusting any forecast as needed) or storing excess material at 

10 3PL 78. Suppher 76 will be billed for any additional freight if the materials are 
returned to the supplier. Suppher 76 will also be billed any additional costs 
iQcurred in storing excess materials with 3PL 78. 

If the comparison yields a short-shipment, supply chain server 74 
evaluates 468 the situation by having the Planner communicate with supplier 76 

1 5 and customer 72. This communication helps determine whether the 

short-shipment is merely a late shipment of whether the Planner must allocate 
further supply. The Planner may also discuss the situation with affected 
customers. Thereafter, supply chain server 74 allocates 472 to each customer a 
percentage of the available supply and control branches to step 344 shovm in 

20 Fig, 11, 

Referring now to Fig. 1 1, in step 344, supply chain server 74 
creates a purchase order based upon ASN 332. The purchase order is created 
for each part for each suppher. Supply chain server 74 then creates 350 a 
receipt and generates 346 cross-dock instructions 348 based upon the purchase 
25 order 344. The receipt, like the purchase order, is organized by part and by 
suppher. Cross-dock instructions 348 may include pickup instructions for 
returns by customers. In situations of short shipment, cross-dock instructions 
348 should reflect the Planner's allocations as discussed above. Upon receipt of 
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a non-conforming shipment, 3PL 78 will notify supply chain server 74. A 
complete explanation of cross-dock instructions 348 is provided below in the 
discussion of the Fulfillment Module, 

After an inherent delay 352 which insures that all week 0 
5 demands are received and processed, supply chain server 74 matches receipts 
created in step 350 with supply plan 338 created earUer (See Fig. lOA) and 
sales order 290 discussed below in Fig. 17. The matching is done to verify that 
no material has been lost in transit. All sales orders that comprise one purchase 
order should be created before the matching is performed. If the documents do 

10 not match at 356, an error routine 358 is initiated. If receipts created at 350 are 
greater in number or price than sales order 290, possible causes of the problem 
could be a delay in the generation of the sales order. If the receipts are less than 
the sales order 290 in either number or price, possible causes of the problem 
include a data integrity issue or that material was lost at the 3PL or in transit. In 

15 any event, the Planner should intervene. If the receipts created in step 350 
match 356 supply plan 338 and sales order 290 at 356 then supply chain server 
74 moves to steps 360 and 362 where a voucher and a payable, respectively, are 
created. 

Supply chain server then branches, in Fig. 12, to query 364 and 
20 determines whether any debits (or credits) for the particular supplier are 

outstanding. If no debits are outstanding, control branches to step 376 (shown in 
Fig. 13). Otherwise, control branches to step 366 where supply chain server 74 
determines 366 whether there are any open invoices for the particular supplier. 
If there are any open invoices, supply chain server 74 appHes 368 the debit 
25 determined in step 364 to that open invoice and branches to step 372. 

Otherwise, supply chain server 74 applies the debit to future balances with the 
particular supplier and branches to step 372. At 372, supply chain server 74 
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issues 372 a customer credit 374 to customer 72, Thereafter, control of supply 
chain server 74 also branches to step 376. 

Referring now to Fig. 13, at step 376 supply chain server 74 
queries whether payment from customer 72 has been received. If payment has 
5 not been received, supply chain server 74 waits a delay period 378 and then 
continues to query 376 whether customer payment has been received. The 
supplier pajmient is thus delayed until payment is received from the customer. 
The customer payments themselves are aggregated throughout the day. When 
payment is received, control branches to query 380 which determines whether 

10 the payment is through an EFT. If the payment is not through an EFT, supply 
chain server 74 prints check and remittance advice notices at 382 and then 
branches to step 386. Otherwise, supply chain server 74 generates 384 an EFT 
file and then branches to step 386. The EFT information for a specific suppHer 
is part of a master data file. An EFT payment is sent to each supplier at the end 

15 of each day (based on the aggregation of payments from received from 
customers throughout the day). 

At step 386, supply chain server 74 pays suppliers 76 and 3PL 78 
with a check and remittance advice note 388. If the financing option discussed 
below with reference to Fig. 21 is implemented, supply chain server 74 also 

20 sends an EFT file 390 to a bank 392. EFT file 390 is sent to suppUers 76 once a 
day and to 3PLs 78 once a month - based on freight tables. Some time 
thereafter, an account statement 394 is sent to supply chain server 74. Supply 
chain server 74 receives account statement 394 and compares 396 it with the 
EFT File 390 which was transmitted to bank 392, Then, supply chain server 74 

25 generates 398 reports including month-end, quarter-end, etc. reports. 

The Procurement Module is also used in situations where 
customer 72 desires to return materials obtained through supply chain network 
70. Referring to Fig. 14, to initiate the return process, customer 72 makes a 
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request 410 for authorization to return a part to supply chain server 74, Each 
supplier 76 provides supply chain server 74 with a pre-issued return 
authorization 412 for parts supplied by supplier 76. Supply chain server 74 
receives request 410 and return authorization 412 and authorizes 414 the return - 
5 of the materials using predetermined suppUer-specific standards. Supply chain 
server 74 also uses a master supply record (not shown) to determine the source 
of the items to be returned. This master record shows which customers received 
products from corresponding suppUers and dates. In this way, supply chain 
server 74 can ascertain the origin of the product which the customer desires to 
10 retum. 

At step 416, supply chain server 74 sends 416 a retum 
authorization 418 to both customer 72 and suppHer 78. Supply chain server 74 
then queries 420 whether the suppUer, whose materials are to be returned, has 
an established retum process. If the supplier does have such a process, that 

15 process will be used and supply chain server 74 sends 422 corresponding retum 
instructions 424 to the customer 72, Control then branches to step 426 shown 
in Fig. 12. Otherwise, if the supplier does not have an estabUshed retums 
process, control branches to step 440 in Fig, 15. 

Referring again to Fig. 12, at step 426, supply chain server 74 

20 queries whether a retumed product Proof of Delivery 430 has been received 
from the supplier's carrier 96 indicating that the product was retumed to the 
customer. If not, supply chain server 74 waits a delay period 428 and then 
continues to look for receipt of retumed product POD 430, Clearly, if the 
retumed product POD is never received, then no credit will be issued. When 

25 supply chain server 74 receives retumed product POD 430, it issues 432 a debit 
to supplier 76 which is applied when the appropriate payables are processed. 
Control then branches to step 364 as was explained in detail above. 
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Referring to Fig. 15, if the supplier does not have an established 
returns process, at step 440, supply chain server 74 determines 440 whether a 
replacement part is needed for customer 72. If no replacement part is needed, 
control branches to step 426 as was explained above with reference to Fig. 12. 
5 Otherwise, control branches to step 442 where supply chain server 74 
detemiines whether replacement parts are available from any suppliers' 
inventory who has been hsted as a customer's preference or which can provide 
immediate shipment. If parts are not available j&om inventory, control branches 
to step 444 where supply chain server 74 determines whether the replacement 

1 0 parts are required within the current week. If the parts are required within the 
current week, control branches to the Order Management module for an ad hoc 
demand as was described with reference to Fig. 5. If the parts are not required 
within the current week, control branches to the Planning Module and the 
demand is absorbed into future weeks forecasts as, for example, described in 

15 Fig. 6. 

Returning to step 442, if replacement parts are available from 
inventory, supply chain server 74 sends 446 instructions 448 to supplier 76. 
Instructions 448 direct supplier 76 to ship the available replacement parts from 
its inventory immediately. In such an event, supplier 76 is responsible for 

20 shipping costs and uses 3PL 78. Supply chain server 74 also produces 450 
pick-up/delivery instractions 452 which are sent to 3PL 78. Control then 
branches again to step 426 described above with reference to Fig. 12. 

Thus, by centralizing processes which were performed separately 
by suppliers, 3PLs, carriers and customers in the prior art, the Procurement 

25 Module enables transfer of products between suppliers and customers more 
efficiently than prior art supply chains. Moreover, problems in shipment and 
retums by customers are also handled more expediently and efficiently. 
V. Fulfilhnent 
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The Fulfillment Module is involved in ensuring the transportation 
of products from suppliers 76 to customers 72. Referring to Fig. 16, there is 
shown a time-phased Fulfillment Module flow diagram in accordance with the 
invention. Much of the flow of information has akeady been described in detail 
5 with reference to the Planning, Order Management, and Procurement modules 
and so a detailed discussion of such information is omitted for the sake of 
brevity. 

In the Fulfillment Module, supply chain server 74 sends customer forecasts 200 
and week 0 callouts 202 (Fig. 4) to suppliers 76. Suppliers 76 send pick-up 

10 instructions 500 to 3PL 78 regarding the demanded products. Suppliers 76 then 
prepare 502 the products and send ASNs 332 (Fig. lOA) to supply chain server 
74. Soon thereafter, 3PL 78 sends a dispatch notice 504 to carrier 96. Supply 
chain server 74 resolves delivery issues 336, 340, 342 (Figs. lOA, lOB) while 
carrier 96 sends 506 dispatch vehicles to suppliers 76 to pickup the appropriate 

1 5 products. When the dispatch vehicles have obtained the products, a shipment 
pickup notification 524 is sent to supply chain server 74. 

The dispatch vehicles travel to a designated cross-dock location 
(in this case, the 3PL is used as the cross-dock location though it should be clear 
that other locations could be used as is explained in more detail below) and 

20 await arrival of cross-dock instructions. Supply chain server 74 generates and 
sends 346 (Fig. 1 1) cross-dock instructions 348 to 3PL 78. When the dispatch 
vehicles arrive at the cross-dock location, they send an arrival notification 508 
to supply chain server 74. At this point, a cross-dock 510 is performed. 

Unlike prior art supply chains, in supply chain network 70, the 

25 orders of a plurality of customers 72, who order the same or similar parts, are 
grouped together into larger orders to be procured from suppliers 76. Suppliers 
76 then ship, through 3PL 78, a much smaller number of larger orders of these 
parts. In the prior art, suppliers 76 handled each order individually and shipped 
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each order in an individual box. This was very costly because it required 
significant management of all the orders and parts for many customers. 

In the present invention, supply chain server 74 iostructs 3PL 78 
to pick up the larger orders from suppliers 76, take the orders to the cross-dock 
5 point, and then un-pack and sub-ship the products to customers 72. The 

cross-dock point may be strategically located to maximize the efficiency of the 
shipment to the customers. At the cross-dock point itself, there is an automated 
inspection, acceptance, etc. of the arriving products. Errors in the shipment are 
typically fixed at the cross-dock 510, 
10 With respect to the products themselves, the operator of supply 

chain server 74 takes title for customers 72 when the product leaves suppliers' 
76 dock. Title is transferred to customer 72 when the product arrives with the 
customer. The operator of supply chain server 74 also acts as the importer of 
record, 

15 Focusing again on Fig, 16, after cross-dock 5 10 has been performed at the 
cross-dock point (in this case at 3PL 78), a dispatch notice 512 is sent to carrier 
96 requesting a pick up of the products and a shipment notification 262 
(discussed below with reference to Fig. 17) is sent to supply chain server 74. 
The products are then picked up by carrier 96 and transported to the appropriate 

20 customers 72. Customers 72 may request a desired pickup or delivery location. 
While the products are being transported, supply chaia server 74 sends ASN 
332 (Fig. lOA) to customers 72. 3PL 78 may also send a customs ia 
notification 514 and a customs out notification 5 16 to supply chain server 74 as 
appropriate. Such information would then be available to customers 72. After 

25 the products are dropped off with customers 72, carrier 96 sends a proof of 
delivery notification POD 5 1 8 to 3PL 78. 3PL 78 forwards POD 5 1 8 to supply 
chain server 74. 
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Thereafter, customers 72 send payment 298 (Fig. 24) to supply 
chain server 74 and supply chain server 74 forwards payment 298 (minus 
management fees) to suppliers 76, 3PL 78 and carrier 96. 3PL 78 then sends a 
payment reconcihation notification 520 to supply chain server 74. If any refund 
5 is necessary, 3PL 78 sends such a refund 522 to supply chain server 74. Supply 
chain server 74 then forwards refund 522 to customers 72. 

Customers 72 using supply chain server 74 also have the ability to 
track the status of an order throughout the Fulfillment process. This order 
tracking capabiUty may be offered to all the customers 72 using supply chain 
10 server 74 via an Extranet discussed below. 

Thus, by providing suppliers with a smaller nimiber of larger 
orders, and breaking down the larger orders at a cross-dock point, a less costly 
and more efficient Fulfillment process is available than in the prior art. 
Additionally, by having customers, suppUers, BPLs, and carriers all report to a 
15 centralized supply chain server, all parties can receive current information 
concerning shipment processes. In one embodiment, such information is easily 
made available on a web site with information populated by the supply chain 
server, 

VI. Billing and Payment 

20 Once customer demand is fulfilled, the Billmg and Payment 

Module is responsible for defining the rules and activities used in performing 
financial transactions such as billing and processing of customer payments. An 
additional offering of the Billing and Payment Module is to enable the supply 
chain network's customers to view the status of pending orders and track the 

25 status of an order up until the time the customers receive their product. 

In general, after customer demand is fulfilled and a shipment 
notification from 3PL 78 is received, supply chain server 74 triggers the 
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generation of a sales order. At the same time, the shipment notifications are 
reviewed to determine any deviations between expected and actual customer 
shipments. This process helps to identify any short shipments or damage done 
to products either in transit or at the 3PL facility. 
5 A customer may receive several shipments fi'om suppliers via 

supply chain network 70 on a given day. However, the customers preferably 
receive one invoice pei* day that consolidates those shipments into a single bill. 
All financial transactions between supply chain server 74 and customers 72 can 
be, in a preferred embodiment, performed by using EFT (Electronic Funds 

10 Transfer), thereby fiarther reducing overall cycle time. 

Referring now to Figs. 17 and 18, the Billing and Payment 
Module, begins with supply chain server 74 receiving 260 a shipment 
notification 262 from 3PL 78 indicating that the products have been delivered 
to customer 72. The receipt 260 may be through an EDI. Supply chain server 

15 74 validates 264 shipment notification 262 and calculates 266 the order pricing 
of the shipment. In validation 264, supply chain server 74 compares the total 
quantity in shipment notification 262 with a quantity specified in supply plan 
338 (see Fig. 1 1). The comparison could include more than one shipment 
notification per customer part number, and should take into consideration 

20 pre-defined tolerances. If supply chain server 74 determines 270, that the 

shipment notification is valid, validation 264 ends. Otherwise, an error routine 
272 is performed as was explained above with reference to Fig. lOB for error 
routine 342, If an error did occur, this is indicative of a data integrity issue 
(shipment notification accuracy) or a 3PL performance issue (material lost or 

25 damaged at 3PL facility or in transit). In any event. Planner intervention is used 
to implement both short and over shipment resolutions in error routine 272. 

In calculate order pricing circuit 266, the price of the order 
associated with shipment notification 262 is calculated based upon cross-dock 
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instructions 346 (Fig, 16), a contract 276 between the supplier 76 and customer 
72, and the actual product 278 that was shipped. This cost is based on the 
number of components purchased and prices negotiated with supplier 76, 
Additional costs are added for services not included in the basic management 
5 fee. These could include, for example, expedited delivery, special labeling or 
packaging, etc. Finally, an ad hoc order may be given an additional charge. 

In addition to the charges for the products themselves, supply 
chain server 74 also calculates 280 the freight charges associated with shipping 
the products based upon a freight table 282 having standard freight charges. In 

10 general, freight charge is based upon weight, number of pieces in the shipment, 
and the freight type (e.g., a pallet, package, etc.). A reconciliation may be used 
periodically to make adjustments to the customer's accounts based upon 
reconciUation by 3PL 78. Some prior art techniques generated sales orders too 
soon and so freight charges needed to be applied after the sales order. As can 

15 be discemed, such a problem is not present in the architecture of the present 
invention. 

Then supply chain server 74 calculates 284 the sales order total 
using applicable rate tables 286. These tables are used to calculate custom 
duties and exchange rates. Insurance charges are added, as well as value added 
20 taxes and sales taxes. Supply chain server 74 then generates 288 a sales order 
290. In a preferred embodiment, a single sales order is generated per customer 
part number and the charges are itemized - for example, freight, taxes, 
additional services, etc. 

Referring now also to Fig. 18, supply chain server 74 then proceeds to steps 292 
25 and 294 where it generates 292 and sends 294 an invoice 296 for sales order 
290 to customer 72. The generation 292 of invoices will be performed 
automatically for each order using electronic invoice outlinmg terms for each 
sales order. The payment terms are based on the shipment date and v^U include 
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itemized charges as referenced above. With respect to the sending 292 of 
invoice 296, all invoices going to the same customer should be consolidated 
every day and so the customer will receive one invoice per day. Sending 292 
thus creates a receivable. 
5 At some point thereafter, customer 72 sends a customer payment 

298 to supply chain server 74 preferably through an electronic funds transfer 
(EFT). Supply chain server 74 attempts to receive payment 298 at 300, If 
payment 298 is not received within a contractually defined period of time, an 
error routine 304 is performed where supply chain server 74 contacts either the 

10 customer or the corresponding bank. If payment 298 is received within the 
defined period of time, payment 298 is processed 302 so that incoming 
payments are matched with open invoices. The account of the customer who 
sent in payment 298 is reviewed for any other outstanding invoices (credit or 
debit balances) and payment 298 is appKed to that customer's account. Finally, 

15 at 306, supply chain server 74 detennines whether customer 72 made a fiill 
payment or overpaid for a given invoice 296. If there was no problem with 
payment 298, the invoice routine ends. Otherwise, error routine 308 is 
implemented where either a collection process is initiated based on the 
customer's past history or a credit is applied to the customer's account in the 

20 event of an overpayment As a plurahty of suppHers 76 may have provided 
parts for customer 72, payment 298 may relate to a plurahty of suppliers 76 and 
may need to be broken up and distributed to suppUers 76 accordingly. 
Thus, the centraUzation of control of supply chain network 70 in supply chain 
server 74 allows suppUers to avoid the costs incurred in managing billing 

25 processes with customers. 



Vn. Information Management 
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Supply chain server 74 accumulates valuable data that can be 
provided to the supply chain network participants. In a preferred embodiment, 
the information delivery capability is implemented primarily by a secure 
Extranet site. Information delivery is very useftil to a supply chain network's 
5 business model, as an efficient supply chain network incorporates both 
accessibility to, and visibility of, real-time information. 

Information delivery, rather than being a discrete process that 
happens periodically, is a, capability that enables an essentially continuous 
conmnmication of information between supply chain server 74 and its business 

10 partners, (e.g., 24 hours-a-day, 7 days-a-week). In addition, the information 
delivery capabihty provides the means for customers (and potentially suppliers 
and 3PLs) to initiate workflow processes. For example, although the process 
for the customer's ability to abort an order is located in the Planning Module, 
information delivery will handle the commimication of the abort code (e.g. a 

15 button on the Extranet that triggers an email or EDI message to initiate the work 
flow). Fig. 19 shows some information which can be provided to users of 
supply chain network 70. The information delivery process allows information 
to be delivered in a very timely maimer, according to the needs of the supply 
chain network participants. 

20 As can be discerned, the type of information available to Customers, Suppliers 
and the 3PL includes but is not limited to: order-specific information/statistics 
and customer-specific statistics (e.g. Week-to-date, Month-to-date, 
Year-to-date, etc.), 

Vni. Financing 

25 The structure of supply chain network 70 also enables (but does 

not require) the possibility of providing new forms of financing for customers 
procuring products. As stated above, in prior art forms of financing, a supplier 
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gave a customer a payment temi which was frequently ignored by the customer. 
Suppliers would therefore increase the prices of products (de facto interest) to 
compensate for prospective losses due to buyers not paying on time. Sellers 
were also at the mercy of unreasonable prices from distributors when sellers . 
5 wished to sell products early to improve their balance sheets. 

The invention, in providing a three party architecture (instead of 
just the supplier and customer of the prior art) removes the de facto interest and 
the prior art distributor. Referring fnst to Fig. 20, there is shown one example of 
the flow of title and payment in supply chain network 70. As stated above in 

10 the description of the Fulfillment Module, the operator of supply chain server 
74 takes title of products 278 once products 278 leave supplier 76. Products 
278 travel to cross-dock 510 and then to customer 72. Customer 72 uses 536 
the products and sends payment 538 to supply chain server 74 (e.g., at the 
cross-dock point). Supply chain server 74 receives 540 payment 538 

15 and sends it to supplier 76. SuppUer 76 receives payment 538 and deposits 542 
the payment in the supplier's bank. 

An alternative form of financing is shown in Fig. 21. As with the 
flow shown in Fig. 20, products 278 are sent to cross-dock 510. At that time, a 
copy of the customer invoice 532 is sent to a financier or bank 392 as collateral 

20 for payment of the customer's invoice. Bank 392 procures the necessary 

financing 534 for customer invoice 532 and sends it back to supply chain server 
74 at 540. Supply chain server 74 then forwards financing 534 to suppHer 76 
who then deposits 542 financing 534 m the supplier's bank. Supplier 76, 
therefore, gets paid soon after products 278 are shipped. Bank 392 effectively 

25 loans customer 72 the financing needed to pay suppher 76 and supply chain 
server 74 secures this obligation of customer 72. Customer 72 continues to use 
536 products 278 and then produces payment 538 which is now sent directly to 
bank 392. Bank 392 deposits 544 payment 538, sends 546 invoice 532 back to 
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customer 72 marked as paid and sends a notification 548 to supply chain server 
74 indicating that invoice 532 was paid. 

In this way, once product 278 is delivered, customer 72 still has a 
payable on its records, even though supply chain server 74 is securing an 
5 obUgation on the customer's behalf. The payable itself is actually to supply 
chain server 74 or bank 342 and not to supplier 76. Such a payment schedule is 
extended to customers with exemplary credit. Further, if the customer does not 
pay on time, supply chain server 74 has the option to hold back on the flow of 
parts to customer 72 thereby causing customer 72 great expenses. Suppher 76 

10 benefits in that it receives an earlier and regular payment. As supply chain 
server 74 pays suppliers 76 on time, suppliers 76 no longer need to charge de 
facto interest This cost savings is passed to customer 72 and realized as profit 
for the operator of supply chain server 74. 

When suppliers 76 desire to ship products 278 before a time 

15 necessary to satisfy customers 72, supply chain server 74 can safely retaia some 
of these products based upon customer forecasts 200 and charge a lower interest 
rate to suppliers 76 than that charged by distributors of the prior art. 

Using the above described techniques, supply chain server 74 can 
arrange payment term financing in order to leverage more favorable pricing or 

20 to create a more appealing balance sheet for the parties involved. For example, 
as suppliers can be paid sooner than in prior art supply chains, suppliers are 
more willing to allow for price concessions and lower financing costs. Supply 
chain server 74 can arrange financing that permits inventory to be taken off 
balance sheets and off premises, 

25 Supply chain server 74 can also shift the risks in changes in 

commodity pricing to more risk inclined parties. For example, in volatile 
commodities (e.g.. Dynamic Random Access Memories - DRAMs), by 
controlling the flow of products and cash, server 74 can also provide risk 
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Shifting products such as hedges, calls, puts, etc. Prior art supply chains could 
not provide such products because there was not a single party who controlled 
products and cash. 

Server 74 can also provide iasurance that was not available id the prior art. As 
5 server 74 is connected with midtiple customers and suppliers, server 74 can 
plan for volatile swings in demand or supply of products. For example, server 
74 can receive extra products from suppliers and retain these products in case 
customers experience an unforeseen increase in demand. The extra products 
received by server 74 are determined by actuarial calculations based upon prior 
10 forecasts. These extra products are updated periodically so that they remain 
fresh aad not outdated. In this way, server 74 insures for demand spikes and 
supply shortages. 

Thus, the provision of supply chain server 74 enables the parties of the supply 
chain network to use jSnancing options not available in the prior art, 
1 5 Additionally, suppliers can provide products more cheaply because de facto 
interest is no longer necessary. 

IX. Architecture 

Supply chain network 70 can be set up in many ways. A general 
architectural set up is shown in Fig. 22. Supply chain server 74 is shown 
20 coupled to all of customers 72, suppliers 74, 3PL 78, banks 392 and carriers 76. 
This connection could be through, for example, a network 560 such as the 
Intemet. 

If network 560 is used, the, communication among the parties shown in Fig. 22 
could be through any know arrangement for accessing a communication server, 
25 such as dial-up serial line interface protocol/point to point protocol 

("SLIP/PPP"), an Integrated Services Digital Server ("ISDN"), a dedicated 
leased-line service, broad band (cable) access, a Digital Subscriber Line 
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("DSL"), asynchronous transfer mode ("ATM") or other access techniques. If 
supply chain server 74 is used to host a web page that is accessed by one of the 
parties of Fig. 22, supply chain server 74 should be able to provide web page 
HTML and/or Java data. Supply chain server 74 is not limited to such hardware 
5 requirements. 

Supply chain server 74 itself can be implemented using many known hardware 
structures. In its most general sense, supply chain server 74 can be 
implemented using a structm:e like that shown in Fig. 23. A CPU 562 is 
coupled to a ROM 564, a RAM 566, a storage device 568, a server device 570 
10 and an input device 572 through a bus 574. Again, supply chain server 74 is 
not limited to these structures. 

Referring to Fig. 24, there is shown a more detailed architecture of supply chain 
server 74. Supply chain server 74 includes an extranet manager 580, an ERP 
system 584, a planner support tool 586, and a messaging services section 588 

15 all coupled to a system monitor 582. System monitor 582 monitors the 
operation of all the components of server 74 and facilitates the flow of 
information among these components. As shown in Fig. 24, customers 72 and 
suppliers 74 can communicate with extranet manager 580 through a firewall 
590. Customers 72, suppliers 74, 3PLs 78 and banks 392 all communicate with 

20 messaging services section 588 of supply chain server 74 also through firewall 
590. 

Extranet manager 580 provides customers 72 and suppUers 74 
with access to order and forecast information, access to any premium 
information services contracted with supply chain server 74, and access to 
25 Customer Master Data which is bibliographic information (e.g. name, address, 
account number, etc.) of customers. Extranet manager 580 performs this 
fimction by displaying web pages and generating new web pages with 
information received firom ERP system 584 discussed below. Finally, Extranet 
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manager 580 manages site membership and security and provides secure 
commimication of data to and jfrom server 74. 

ERP (enterprise resources planning) system 584 provides server 74 with 
appUcations and systems support for jSnancial, order management, demand 
5 management, procurement, and other enterprise processing capabilities, ERP 
system 584 allows for incorporation of data from suppliers 74, customers 72, 
logistics providers 78 and financial institutions 392 ("partners") and stores and 
manages the data from these partners in a standard format. ERP system 584 
also provides employees of server 74 with real time access to enterprise 
10 information and provides workflow capabihties to ensure completidn of 
business processes. Finally, ERP system 584 keeps track of the Customer 
Master Data. 

Messaging services section 588 streamlines communications 
between supply chain server 74 and all of its partners. Messaging services 

1 5 section 588 translates all received information into a standardized format which 
is input into ERP system 584. Conversely, messaging services section 588 also 
receives information from ERP system 584 and generates outgoing messages in 
the format expected by a particular partner. Messaging services section 588 
manages secure data transmission between server 74 and its partners, allows use 

20 of the Internet for all transmissions, and provides logging and serialization of all 
transmissions for audit purposes. 

Planner support tool 586 allows Planners working for server 74 to 
manipulate forecast, demand and supply data. Planner support tool 586 
aggregates data extracted from ERP system 584 thereby facilitating flexible, 

25 configurable analysis methods, providing a wide range of reporting capabilities, 
providing a definition of exception conditions in the analysis process, providing 
courses of action (workflow) should an exception occur, providing secure 
access to data, and allowing for multiple user access to tiiis data while 
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preserving the integrity of the data. By providing a Planner Support Tool that is 
external to Extranet 580, which works with ERP system 584, and which is 
coupled to messaging services station 588, a desirable supply-demand balance 
can be achieved. 

5 X. Summary 

Thus, by providing a supply chain server to handle many of the 
processes previously performed by individual entities of the prior art, a more 
efficient and cost minimizmg architecture is realized. By consolidating 
purchases and supply chain management, supply chaia server eliminates many 

10 of the steps and costs expended by customers and suppliers of prior art supply 
chains. Customers appreciate: lower prices, lower expenses for freight, buying, 
and planning systems, etc., faster and more reUable deliveries, shorter lead 
times and lower inventories, supply chain management savings, lower duties 
and taxes, product expertise, complete supply chain visibility, improved data 

15 integrity, improved profits, improved service to their customers, improved 
suppUers, and improved decision making. SuppUers benefit in: lower selling 
expenses, lower planning costs, lower inventories, improved deUvery, lower 
product costs, visibility of demand, lower operating expenses, and reduced 
manufacturing costs from smoother production flows. This all leads to 

20 improved profitability while selling at lower prices which, in tum, will increase 
demand. Both customers and suppliers may have access to a secure web site 
hosted by supply chain server which will provide valuable information that was 
not available in the prior art. This iiLformation includes customer buying habits, 
and the size and growth rates of markets served. As the historical data detailing 

25 customer's bujdng pattems grows, it will become more expensive to switch to 
another supply chain network. 
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The costs of supply chain server will be borne by customers based upon the 
number of part numbers and the cumulative value of purchases. Suppliers need 
not be charged a fee so that the lowest possible price may be provided by 
suppliers. As the supply chain network is procuring products in bulk, it will 
5 receive a lower cost for the items and will realize this lower cost in profits. 

Although demand and supply of products have been discussed, it 
should be clear that demand and supply of any resource, including services, is 
also within the scope of the invention. The term "product" throughout the 
specification thus refers to any such resource or service. For example, 

10 customers could be individuals desiring bandwidth on a trunk line in a network. 
Suppliers would then be sources of network bandwidth. Customers could also 
be, for example, individuals desiring airplane tickets or theater seats from 
corresponding suppUers. 

While preferred embodiments of the invention have been 

1 5 disclosed, various modes of canying out the principles disclosed herein are 
contemplated as being within the scope of the following claims. Therefore, it is 
understood that the scope of the invention is not to be limited except as 
otherwise set forth in the claims. 
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WHATIS CLAIMED IS: 

1 . A method for processing customer demands, the method 
comprising: 

receiving forecasted demands from at least one customer; 
5 analyzing the forecasted demands to determine whether the 

forecasted demands are valid; and 

sending the forecasted demands to at least one suppUer when the 
forecasted demands are valid. 

2. The method as recited in claim 1, wherein the receiving the 

10 forecasted demands further includes extrapolating the forecasted demands based 
on expected demand by the customer. 

3. The method as recited in claim 2, wherein the extrapolating is 
based on historical data of the forecasted demands. 

4. The method as recited in claim 2, wherein the extrapolating is 
15 based on information supplied by the customer. 

5 . The method as recited in claim 1 , further comprising requiring the 
suppUer to follow a production protocol in light of the sending. 

6. The method as recited in claim 1, further comprising requiring the 
suppUer to follow an inventory protocol in light of the sending. 

20 7. The method as recited in claim 1, further comprising sending an 

exception notice to the customer when the demands are not valid. 
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8. The method as recited in claim 1, wherein the customer demands 
are received by a supply chain server and wherein the analyzing includes 
checking at least one of: the credit of the customer, whether the demand is a 
complete forecast, whether all information is complete and accurate, whether 

5 the customer has a contract with the supply chain server, and whether a part 
number associated with the demand is included in the contract between the 
supply chain server and the customer. 

9, The method as recited in claim 1, wherein the forecasted demands 
relate to demands for a plurality of time periods from the at least one customer. 

10 10. The method as recited in claim 1 , further comprising: 

accumulating the forecasted demands thereby producing an accumulated 
forecast; and 

sending the accumulated forecast to the at least one supplier when the 
demands are vaUd. 

15 11. The method as recited in claim 10, wherein the forecasted 

demands come from a plurality of customers. 

12. The method as recited in claim 1, wherein the forecasted demands 
are in a format determined by the customer. 

13. The method as recited in claim 12, fijrther comprismg converting 
20 the forecasted demands into a different format. 

14. The method as recited in claim 12, wherein the forecasted 
demands are received in one of an email, a spreadsheet, and an XML fomiat. 
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15. The method as recited in claim 1, wherein the forecasted demands 
relate to products. 

16. The method as recited in claim 1, wherein the forecasted demands 
relate to services. 

5 17. The method as recited in claim 1, wherein the forecasted demands 

relate to bandwidth in a network. 

1 8. The method as recited in claim 1, wherein the forecasted demands 
relate to airline tickets. 

19. The method as recited in claim 1 , further comprising sending an 
10 abort code to the customer, the abort code enabling the customer to abort an 

order relating to one of the forecasted demands. 

20. The method as recited in claim 19, further comprising canceling 
an order corresponding to one of the forecasted demands if the customer sends 
the abort code. 

15 21. The method as recited in claim 1 , further comprising sending 

products corresponding to the forecasted demands from the supplier to the 
customer. 

22. The method as recited in claim 21, further comprising providing 
tracking information relating to the products, to at least one of the customer and 
20 the suppHer. 
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23 . The method as recited in claim 22, wherein the trackmg 
information is provided by producing a web site accessible by at least one of the 
customer and the supplier. 

24. The method as recited in claim 22, wherein the tracking 

5 information includes information relating to potential bottlenecks between the 
supplier and the customer. 

25 . The method as recited in claim 24, wherein the bottlenecks 
include 

customs. 



10 26. The method as recited in claim 1, further comprising 

receiving a return request by the at least one customer for a particular 
product; 

returning the particular product to a corresponding supplier; and 
determining whether the customer desires a replacement product; 
15 wherein 

the receiving is performed by a supply chain server in a supply chain network. 

27. The method as recited in claim 26, further comprising 
determining whether the replacement product is available from at least one of 
the suppliers m the supply chain network. 

20 28. The method as recited in claim 27, further comprising adjusting 

the forecasted demands when the replacement product is not available from the 
suppliers in the supply chain network. 
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29. A method for processing customer demands for products in a 
supply chain network, the method comprising: 

receiving forecasted demands from a plurality of customers; 
accumulating the forecasted demands thereby producing an accumulated 
5 forecast; 

sending the accumulated forecast to at least one supplier; 

sending products corresponding to the accumulated forecast from the at 
least one supplier to a cross-dock point; 

assembling the products at the cross-dock point based upon particular 
10 customers who produced the forecasted demands; and 

sending corresponding products to the particular customers who 
produced the forecasted demands. 

30. The method as recited in claim 29, further comprising providing 
tracking information relating to the products, to at least one of the customer and 

15 the supplier. 

3 1 . The method as claimed in claim 30, wherein the tracking 
information is provided by producing a web site accessible by at least one of the 
customer and the supplier. 

32. The method as recited in claim 30, wherein the tracking 

20 information includes movement of the products before the cross-dock point. 



33 . The method as recited in claim 30, wherein the tracking 
information inpludes movement of the products after the cross-dock point. 
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34. The method as recited in claim 30, wherein the tracking 
information includes movement of the products through potential bottlenecks. 

3 5 . The method as recited in claim 34, wherein the potential 
bottlenecks includes customs. 

5 36. The method as recited in claim 29, wherein the potential 

bottlenecks includes the cross-dock point 

37. The method as recited in claim 29, wherein the cross-dock point is 
specified by the particular customers. 

38. The method as recited in claim 29, wherein the accumulating 
10 includes grouping together customer demands for products which are 

substantially interchangeable. 

39. The method as recited in claim 29, wherein the sending products 
and the assembling the products results in the at least one supplier saving time 
in managing the forecasted demands. 

15 40. The method as recited in claim 29, further comprising comparing 

the products at the cross-dock with the accumulated forecast. 

4 1 , The method as recited in claim 40, further comprising, if the 
comparing indicates that the products at the cross-dock and the accumulated 
forecast do not match, determining if the products at the cross-dock represent an 
20 over-shipment or an under-shipment. 
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42. The method as recited in claim 41, further comprising, when the 
products at the cross-dock represent an over-shipment, determining a 
disposition of products at the cross-dock in excess of the accumulated forecast. 

43 . The method as recited in claim 41, further comprising, when the 
5 products at the cross-dock represent an under-shipment, allocating available 

supply of the products among the particular customers who produced the 
accumulated forecast. 

44. A method of providing a customer with a demanded product, the 
1 0 method comprising: 

receiving a demand from the customer indicating the demanded product 
desired from a particular supplier; 

determining whether the particular supplier can supply the demanded 
product; and 

15 if the particular supplier cannot supply the demanded product, 

detemiining whether another supplier can supply the demanded product 

45 . The method as recited in claim 44, further comprising sending the 
demanded product from the another suppUer to the customer when the another 
suppher can supply the demanded product. 

20 46, The method as recited in claim 44, wherein the demand is an ad 

hoc demand. 



47. The method as recited in claim 44, further comprising converting 
the demand into one or more corresponding supplier part numbers. 
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48. The method as recited in claim 44, further comprising: 
receiving demands from a plurality of customers in a supply chain 

network; 

determining whether suppUers in the supply chain network can supply 
5 the demands of the plurality of customers; and 

if the suppUers in the supply chain network cannot supply the demands 
of the plurality of customers, distributing products that are available from the 
suppliers among the plurahty of customers. 

49. The method as recited in claim 48, wherem the distributing is 
1 0 perforated on a pro rata basis. 

50. A method of financing a purchase of a product by at least one 
customer from at least one suppUer, the method comprising: 

sending the product to the customer from the suppUer; 
sending a financing payment for the product from a bank to a third party; 
1 5 forwarding the financing payment from the third party to the supplier; 

and 

sending a customer payment for the product from the customer to the 

bank. 

5 1 . The method as recited in claim 50, wherein: 

20 the product comprises a plurahty of products from a plurality of 

suppUers; and 

the customer payment is a batch payment for the plurality of suppliers. 

52. The method as recited in claim 50, wherein the step of sending the 
product comprises: 
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sending the product from the supplier to a cross-dock point; and 
sending the product from the cross-dock point to the customer. 

53 . The method as recited in claim 50, ftirther comprising providing a 
risk shifting service to at least one of the customer and the supplier. 

5 54. The method as recited in claim 5 1 , wherein the risk shifting 

service is one of a hedge, a call and a put relating to a price of the product. 

55. The method as recited in claim 48, wherein the step of sending the 
product comprises: 

transferring title of the product from the supplier to the third party; and 
10 transferring the title of the product from the third party to the customer. 

56. A method for processing customer demands received in a supply 
chain network, the method comprisiag: 

receivLQg forecasted demands from a plurality of customers by a supply 
chain server; 

15 aggregating the forecasted demands into an aggregated forecast; and 

sending the aggregated forecast from the supply chain server to at least 
one supplier. 

57. A method of providiQg a customer with a demanded product, the 
method comprising: 

20 receiving a forecasted demand from at least one customer for delivery of 

a specified product at a first time, the first time requiring a suppHer to supply 
the specified product by a second time; 
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receiving the product from the suppUer before the second time without 
chargmg the supplier an extra fee for receivmg the product before tiie second 
time; and 

delivering the product to the customer at approximately the first time. 

5 58. A method for processing customer demands for products in a 

supply chain network, the method comprising: 
receiving the customer demands; 

aggregating the customer demands to produce an aggregated demand; 
sending the aggregated demand to at least one supplier; 
10 sending products corresponding to the aggregated demand from the at 

least one supplier to a cross-dock point; 

assembling the products at the cross-dock point based upon particular 
customers who produced the customer demands; and 

sending corresponding products to the particular customers who 
15 produced the customer demands. 

59. A method for insuring for supply/demand fluctuation for one or 
more products demanded by at least one customer from at least one suppher, the 
method comprising: 

receiving at least one product from at least one supplier; 
20 retaining the product until at least one of the customer experiences an 

unforeseen increase in demand for the product and the supplier experiences an 
unforeseen shortage in supply of the product; and 

sending the product to a corresponding customer. 

60. The method as recited in claim 59, wherein the product is a 
25 service. 
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61 . The method as recited in claim 59, further comprising: 
receiving forecasted demands from at least one customer regarding the at 

least one product. 

62. The method as recited in claim 6 1 , wherein the receiving 

5 forecasted demands includes extrapolating the forecasted demands based on 
expected demand by the customer. 

63. The method as recited in claim 62, wherein the extrapolating is 
determined by actuarial calculations. 

64. The method as recited in claim 59, wherein the products are 
10 replaced often enough so that the products remain fresh. 

65. A method for processing a demand by a customer for a product in 
a supply chain network, the method comprising: 

receiving the demand; 

determining whether the demand can be ftilfiUed by supply of suppliers 
15 coupled to the supply chain network; and 

when the demand cannot be ftilfilled by the supphers coupled to the 
supply chain network, contacting the customer and the suppliers to ascertain 
whether one of the demand and the supply can be altered. 



20 



66. The method as recited in claim 65, wherein the demand is 
received from plurality of customers; and 

the contacting includes contacting the plurality of customers. 
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67. The method as recited in claim 65, wherein the demand comprises 
a forecast for products desired by the customer over a plurality of time periods. 

68. The method as recited in claim 65, wherein the determining 
includes iterating through the time periods and determining available supply for 

5 each time period. 

69. The method as recited in claim 67, wherein the time periods are 

weeks. 

70. A system for processing customer demands, the system 
10 comprising: 

a supply chain server coupled to at least one customer and at least one supplier, 
the supply chain server including a messaging services system and an ERP 
system; wherein: 

the messaging services system receives forecasted demands from the at 
1 5 least one customer; 

the ERP system analyzes the forecasted demands received by the 
messaging services system to determine whether the forecasted demands are 
valid; and 

the messaging system sends the forecasted demands to the at least one 
20 supplier when the forecasted demands are valid. 

71 . The system as recited in claim 70, wherein the ERP system 
further extrapolates the forecasted demands based on expected demand by the 

• customer. 
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72, The system as recited in claim 71, wherein the ERP system 
extrapolates the forecasted demands based on historical data of the forecasted 
demands, 

73. The system as recited in claim 71, wherein the ERP system 
5 extrapolates the forecasted demands based on information supplied by the 

customer. 



74. The system as recited in claim 70, further comprising a 
contractual agreement requiring the supplier to follow a production protocol in 
Ught of the forecasted demands sent by the messaging services system. 

10 75 . The system as recited in claim 70, further comprising a 

contractual agreement requiring the supplier to follow a inventory protocol in 
light of the forecasted demands sent by the messaging services system. 

76. The system as recited in claim 70, wherein the messaging services 
system sends an exception notice to the customer when the ERP system 

1 5 determines that the demands are not valid. 

77. The system as recited in claim 70, wherein the ERP system 
analyzes the forecasted demands by checking at least one of: the credit of the 
customer, whether the demand is a complete forecast, whether all information is 
complete and accurate, whether the customer has a contract with the supply 

20 chain server, and whether a part number associated with the demand is included 
in the contract between the supply chain server and the customer. 
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78. The system as recited in claim 70, wherein the forecasted 
demands relate to demands for a pluraUty of time periods Jfrom the at least one 
customer. 

79. The system as recited in claim 70, whereia: 

5 the ERP system further accumulates the forecasted demands thereby 

producing an accumulated forecast; and 

the messaging services system sends the accumulated forecast to at least 
one of the suppliers when the demands are vaHd. 

80. The system as recited in claim 79, wherein the accumulated 
10 forecasted demands come from a plurality of customers. 

8 1 . The system as recited in claim 70, wherein the forecasted 
demands are in a format determined by the customer. 

82. The system as recited ia claim 81, wherein the messaging services 
system further converts the forecasted demands into a different format. 

15 83 . The system as recited in claim 8 1 , wherein the forecasted 

demands are received in one of an EDI, an email, a spreadsheet, and an XML 
format. 

84. The system as recited in claim 70, wherein the forecasted 
demands relate to products. 

20 85. The system as recited in claim 70, wherein the forecasted 

demands relate to services. 
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86. The system as recited in claim 70, wherein the forecasted 
demands relate to bandwidth in a network, 

87. The system as recited in claim 70, wherein the forecasted 
demands relate to airline tickets. 

5 88. The system as recited in claim 70, wherein.the messaging system 

further sends an abort code to the customer, the abort code enabling the 
customer to abort an order relating to one of the forecasted demands. 

89. The system as recited in claim 88, wherein the ERP system 
further cancels an order corresponding to one of the forecasted demands upon 

10 receiving or abort code from the customer sends the abort code. 

90. The system as recited in claim 70, wherein: 

the supply chain server is further connected to at least one logistics 
provider; and 

the ERP system further sends a command to the logistics provider so that 
15 the logiistics provider transfers products corresponding to the forecasted 
demands from the supplier to the customer in response to orders from the 
supply chain server. 

91. The system as recited ui claim 90, wherein the supply chain server 
further comprises an extranet manager, the extranet manager providing tracking 

20 information relating to the products. 
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92. The system as claimed in claim 91, wherein the extranet manager 
provides the tracking information by producing a web site accessible by at least 
one of the customer and the supplier. 

93 . The system as recited in claim 9 1 , wherein the tracking 

5 information includes information regarding the status of the product through 
potential bottlenecks between the suppUer and the customer. 

94. The system as recited in claim 93, wherein the bottlenecks include 
customs. 

95. The system as recited in claim 70, wherein: 
the supply chain server is further coupled to a logistics provider; 
the messaging services system receives a retum request by the at least 

one customer for a particular product; 

the ERP system controls the logistics provider to retum the particular 
product to a corresponding supplier; and 

the ERP system determines whether the customer desires a replacement 
product. 

96. The system as recited iq claim 95, wherein the ERP system 
further determines whether the replacement product is available from supphers 
in the system. 

20 

97. The system as recited in claim 96, wherein the ERP system 
further adjusts the forecasted demands when the replacement product is not 
available from suppliers in the system. 



10 



15 
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98. A system for processing customer demands for products, the 
system comprising: 

a supply chain server coupled to at least one customer, at least one 
supplier, and a 

5 logistics provider, the supply chain server including a messaging services 

system and an ERP system; wherein 

the messaging services system receives forecasted demands from a 
plurality of customers; 

the ERP system accumulates the forecasted demands thereby producing 
10 an accumulated forecast; 

the messaging services system sends the accumulated forecast to at least 
one supplier; 

the ERP system controls the logistics provider to transfer products 
corresponding to the accumulated forecast from the at least one assemble 
1 5 suppUer to a cross-dock point; 

the ERP system further controls the logistics provider to assemble the 
products at the cross-dock point based upon particular customers who produced 
the forecasted demands; and 

the ERP system controls the logistics provider to send corresponding 
20 products to the particular customers who produced the forecasted demands. 

99. The system as recited in claim 98, wherein the supply chain server 
further comprises an extranet manager which provides tracking information 
relating to the products. 

100. The system as recited in claim 99, wherein the extranet manager 
25 provides the tracking information by producing a web site accessible to at least 

one of the customer and the supplier. 
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101 . The system as recited in claim 100, wherein the trackuig 
information includes movement of the products before the cross-dock point. 

102. The system as recited m claim 100, wherein the tracking 
information includes movement of the products after the cross-dock point. 

5 103. The system as recited m claim 100, wherein the tracking 

information includes movement of the products through potential bottlenecks. 

104. The system as recited in claim 103, wherein the potential 
bottlenecks includes customs, 

105 . The system as recited in claim 1 04, wherein the potential 
10 bottlenecks includes the cross-dock point. 

106. The system as recited in claim 105, wherein the cross-dock point 
is specified by the particular customers. 

107. The system as recited in claim 98, wherein the ERP system 
accumulates the forecasted demands by grouping together customer demands 

15 for products which are substantially interchangeable. 

108. The system as recited in claun 98, wherein the ERP system 
controlling the sending of the products and the assembling of the products 
results in the at least one supplier saving time in managing the forecasted 
demands. 
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109. The system as recited in claim 98, wherein the supply chain server 
further comprises a planner tool which compares the products at the cross-dock 
with the accumulated forecast. 

110. The system as recited in claim 109, wherein, if the planner tool 

5 indicates that the products at the cross-dock and the accumulated forecast do not 
match, the planner tool determines if the products at the cross-dock represent an 
over-shipment or an under-shipment. 



111. The system as recited in claim 110, wherein when the products at 
the cross-dock represent an over-shipment, the plaimer tool determines a 

10 disposition of products at the cross-dock in excess of the accumulated forecast 

1 12. The system as recited in claim 110, wherein when the products at 
the cross-dock represent an under-shipment, the planner tool allocates available 
supply of the products among the particular customers who produced the 
accumulated forecast. 

15 

113. A system for providing a customer with a demanded product, the 
system comprising: 

a supply chain server coupled to at least one customer and at least one 
suppUer, the 

20 supply chain server including a messaging services system and an ERP 

system; whereia 

the messaging system receives a demand from the customer indicating 
the demanded product desired from a particular supplier; 

the ERP system determines whether the particular supplier can supply 
25 the demanded product; and 
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if the particular supplier caimot supply the demanded product, the ERP 
system determines whether another supplier can supply the demanded product. 

1 14. The system as recited m claim 113, wherein: 

the supply chain server is coupled to a logistics provider; and 
5 the ERP system further controls the logistics provider to send the 

demanded product from the another supplier to the customer when the another 
supplier can supply the demanded product 

115, The system as recited in claim 1 13, wherein the demand is an ad 
hoc demand. 

10 116. The system as recited in claim 113, wherein the ERP system 

further converts the demand into one or more corresponding suppher part 
numbers. 

1 17. The system as recited in claim 1 13, wherein: 
the messaging system receives demands from a plurality of customers; 
15 the ERP system determines whether the suppliers can supply the 

demands of the plurality of customers; and 

if the suppliers cannot supply the demands of the plurality of customers, 

the ERP system causes distribution of the products that are available from the 

suppliers among the plurality of customers. 



20 



1 1 8. The system as recited in claim 1 17, wherein the distributrag is 
performed on a pro rata basis. 
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119. A system for financing a purchase of a product by at least one 
customer from at least one suppKer, the system comprising: 

a supply chain server coupled to at least one customer, at least one 
supplier, and a logistics provider, wherein the supply chain server controls the 
logistics provider to transfer the product from the suppUer to the customer; and 
a financial institution which sends a financing payment for the product to 
the supply chain server; wherein 

the supply chain server forwards the financing payment to the suppUer; 

and 

the customer sends a customer payment for the product to the bank. 

120. The system as recited in claim 1 19, wherein: 
the product comprises a pluraUty of products from a plurality of 

suppliers; and 

the customer payment is a batch payment for the plurality of suppUers. 

15 121. The system as recited in claim 119, wherein the supply chain 

server controls the logistics provider to: 

send the product from the supplier to a cross-dock point; and 
send the product from the cross-dock point to the customer. 

122. The system as recited in claim 119, wherein the supply chain 

20 server fiirther provides a risk shifting service to at least one of the customer and 
the supplier. 

123. The system as recited in claim 122, wherein the risk shifting 
service is one of a hedge, a call and a put relating to a price of the product. 



5 



10 
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124. The system as recited in claim 1 19, wherein the ERP system 
controls the logistics provider to transfer the product by performing: 

transferring title of the product from the supplier to the supply chain 
server; and 

5 transferring the title of the product from the supply chain server to the 

customer. 

125. A system for processing customer demands received in a supply 
chain network, the supply chain network including a supply chain server 
coupled to at least one customer and at least one supplier, the supply chain 

10 server including a messaging services system and an ERP system; wherein: 
the messaging system receives forecasted demands from a plurality of 
the customers; 

the ERP system aggregates the forecasted demands into an aggregated 
forecast; and 

15 the messaging system sends the aggregated forecast to at least one 

supplier. 

126. A system for providing a customer with a demanded product, the 
system comprising a supply chain server coupled to at least one customer, at 
least one supplier, and at least one logistics provider, the supply chain server 

20 including a messaging services system and an ERP system, wherein 

the messaging system receives a forecasted demand from the at least one 
customer for delivery of a specified product at a first time, the first time 
requiring a suppher to supply the specified product by a second time; 

the ERP system controlling the logistics provider to receive the product 
25 from the supplier before the second time without charging the supplier an extra 
fee for receiving the product before the second time; and 
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^ the ERP system further controls the logistics provider to deliver the 
product to the customer at approximately the first time. 

127. A system for processing customer demands for at least one 
product, the system comprising: 

5 a supply chain server coupled to at least one customer, at least one 

supplier, and a logistics provider, the supply chain server including a messaging 
services system and an ERP system; wherein 

the messaging services system receives the customer demands; 
the ERP system aggregates the customer demands thereby producing an 
10 aggregated demand; 

the messaging services system sends the aggregated demand to at least 
one supplier; 

the ERP system controls the logistics provider to transfer products 
corresponding to the aggregated demand from the at least one supplier to a 
1 5 cross-dock point; 

the ERP system further controls the logistics provider to assemble the 
products at the cross-dock point based upon particular customers who produced 
the customer demands; and 

the ERP system controls the logistics provider to send corresponding 
20 products to the particular customers who produced the customer demands. 

128. A system for processing a demand by a customer for a product, 
the system comprising: 

a supply chain server coupled to at least one customer and at least one 
supplier, the supply chain server including a messaging services system, an 
25 ERP system, and a planner support tool, wherein: 

the messaging system receives the demand; 
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the ERP system determines whether the demand can be fulfilled 
by supply of suppliers coupled to the supply chain network; and 

when the demand cannot be fulfilled by the suppliers coupled to 
the supply chain network, the planner support tool contacts the customer and 
5 the suppliers to ascertain whether one of the demand and the supply can be 
altered. 



129. The system as recited in claim 128, wherein the demand is 
received firom plurality of customers; and 

the planner support tool contacts the plurality of customers. 

10 130. The system as recited m claim 128, wherein the demand 

comprises a forecast for products desired by the customer over a plurality of 
time periods. 

131. The system as recited in claim 128, wherein the planner support 
tool iterates through the time periods and determines available supply for each 
15 time period. 



132. The system as recited in claim 130, wherein the time periods are 

weeks. 
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